0% found this document useful (0 votes)
29 views14 pages

UNIT-3_IOT

Uploaded by

imjyoti1511
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
0% found this document useful (0 votes)
29 views14 pages

UNIT-3_IOT

Uploaded by

imjyoti1511
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/ 14

UNIT-III

Design Principles for Web Connectivity


I) Web Communication Protocols for Connected Devices:
i) Understanding Web communication Protocols using IOT/M2M:
Data of connected devices routes over the web in two types of communication
environments. The environments are :
a) Constrained RESTful Environment (CoRE): IoT devices or M2M devices
communicate between themselves in a Local Area Network. A device typically sends or
receives 10s of bytes. The data gathered after enriching and consolidating from a number
of devices consists of 100s of bytes.
A gateway in the communication framework enables the data of networked
devices that communicate over the Internet using the REST software architecture.
Devices have the constraint in the sense that their data is limited in size compared
to when data interchange between web clients and web servers takes place using HTTP,
Transmission Control Protocol (TCP) and Internet Protocol (IP)
Another constraint is data-routing when Routing Over a network of Low power
and (data) Loss (ROLL). ROLL network is a wireless network with low power
transceiver.
Another constraint is that the devices may sleep most of the time in low power
environment and awaken on an event or when required . Devices’ connectivity may also
break for long periods, have limited up intervals in loss environment.
b) Unconstrained Environment: Web applications use HTTP and RESTful HTTP for web
client and web server communication. A web object consists of 1000s of bytes. Data routes over
IP networks for the Internet. Web applications and services use the IP and TCP protocols for
Internet network and transport layers.
Figure shows device’s local area network connectivity, web connectivity in constrained
and unconstrained RESTful environments and the protocols for communication.

ULNKUMAR, Dept. of MCA,ASCS


The Above figure represents:
• Assume i-devices connected devices network, and local network having connectivity
between devices at physical/ Data Link adaption layer.
• Communication between web objects. Assume that a web object refers to a web client or
web server.
• Web objects’ protocols for sending a request or response; for example, RESTful CoAP,
CoAP client and CoAP server communication over the network and transport layers.
• Transport layer protocols used are Datagram Transport Layer Security (DTLS) and UDP.
Data between web objects route using ROLL network specifications.
• 100s of bytes communicate between the IoT web objects.
• Web objects HTTP client and HTTP server communication over the Internet using the IP
and client/server.
• 1000s of bytes communicate between HTTP web objects using certain protocols for
sending a request or response; For example, RESTful HTTP.

ULNKUMAR, Dept. of MCA,ASCS


ii) Constrained Application Protocol(COAP) :
IETF recommends Constrained Application Protocol (CoAP) which is for Constrained
RESTful Environment(CoRE) using ROLL data network. Features of CoAP are:
• An IETF defined application-support layer protocol.
• CoAP web-objects communicate using request/response interaction model.
• A specialized web-transfer protocol which is used for CoRE using ROLL network.
• It uses object-model for the resources and each object can have single or multiple
instances.
• Each resource can have single or multiple instances.
• An object or resource use CoAP, DTLS (security binding with PSK, RPK and
Certificate) and UDP protocols for sending a request or response.
• Supports the resource directory and resource-discovery functions.
• The resource identifiers use the URIs as follow coap://… .
• Has small message header, 4 bytes are for ver (version), T (message type) [Types are
confirmable, non-confirmable, acknowledgement and reset], TKL (token length), code
(request method or response code), message ID 16-bit identifier, token (optional response
matching token). Confirmable means server must send an acknowledgement, while non-
confirmable means no acknowledgement is required.
• CoRE communication is asynchronous communication over the ROLL.
• Integrates easily with the web using CoAP application cross-protocol proxies. This is
facilitated because HTTP and CoAP, both share the REST model.
• Use of REST: The access by a CoAP object or its resource is thus using :
• the URI
• a subset of MIME types
• a subset of response codes which are used for an HTTP object or resource.
Figure (a) shows direct and indirect accesses of CoAP client objects to a CoAP
server. Figure (b) shows a CoAP client access for lookup of object or resource using a
resource directory. Figure (c) CoAP client and server access using proxies .

ULNKUMAR, Dept. of MCA,ASCS


ii) Lightweight Machine-to-Machine Communication Protocol (LWM2M):
• LWM2M protocol is an application layer protocol specified by Open Mobile
Alliance (OMA) for transfer of service data/messages. It finds applications in M2M. It
enables functionalities for device management in cellular or sensor networks.
Communication protocol ‘light weight’ means that it does not depend on call to the
system resources during execution. Lightweight presently means data transfer formats
between client and server are binary and has Tag Length Value (TLV) or Java Script
Object Notation (JSON) batches of object arrays or resource arrays and transfers up to
100s of bytes unlike the WebPages of 1000s of bytes .
LWM2M specifications and features are as follows:
• An object or resource use CoAP, DTLS, and UDP or SMS protocols for sending a
request or response.
• Use of plain text for a resource or use of JSON during a single data transfer or binary
TLV format data transfer for a package for a batch of resource representations in a single
data transfer.

ULNKUMAR, Dept. of MCA,ASCS


• Interface functions are for—bootstrapping; registration, deregister or updating a client
and its objects; reporting the notifications with new resource values; and service and
management access through the server.
• Use of object model for resources and each object can have single or multiple instances.
Each resource can have single or multiple instances.
• LWM2M client-server interactions are over the access and CoRE networks which
generally use CoAP over ROLL. LWM2M device client and server, generally use CoAP
client server interactions for data interchanges. Examples of CoRE network are GSM,
GPRS, 3GPP and 4G LTE.
• Organisations can register the other LWM2M objects and resources with OMA or other
standards organizations.
• M2M management functions can be M2M Service Bootstrap Function (MSBF) for
credentials of the devices and gateway, and M2M authentication server (MAS) for
security, root key data store and device and data authentication.
The Following Diagram shows the LwM2M Architecture :

ULNKUMAR, Dept. of MCA,ASCS


The architecture consists of three components:
• LwM2M Client: Runs on the end device and ensures a secure connection with the
server.
• LwM2M Server: Manages devices in the cloud, including their configurations and
firmware. It also stores telemetry data sent from the clients.
• LwM2M Bootstrap Server: An optional cloud service that authenticates and provisions
LwM2M client.
II) Message communication protocols for connected devices :
i) Terminology for message Communication :
a) Request/Response(Client/Server):A request/response message exchange refers
to an object (client) requesting for resource(s) and an object (server) sending the
response(s). The objects, for example, HTTP objects may use the REST functions.
b) Publish/Subscribe: Publish/subscribe message exchanges differ from
request/response. A service publishes the messages; for example, a weather information
service publishes the messages of weather reports for the potential receivers. A group
controller publishes the messages;
A service can be availed by one or more clients or brokers. When a client
subscribes to the service, it receives messages from that service. A publish/subscribe
messaging protocol provisions for publication of messages and reception on subscription
(PUT and GET methods) by the registered or authenticated devices.
c) Resource Directory: Resource directory maintains information and values for
each resource type. A resource of a resource type accesses from the RD using URI for the
resource.
d) Resource Discovery: Resource discovery service may advertise (publish) at
regular intervals, the availability of the resources or types of the resources available and
their states. A client discovers the resource type and registers for the RD service.
e) Registration/Registration Update : Registration means a receiver
registers with a service, such as an a RD service. When one or more endpoints or devices or
nodes registers, then that device gets the access to the resources and receives published
messages.
Registration updates means updating for one or more endpoints or
devices or nodes. It also includes unregistering for one or more endpoints.

ULNKUMAR, Dept. of MCA,ASCS


f) Pull (Subscribe/Notify) Data : Pull means pulling a resource, value, message or
data of a resource-type by registering and subscribing. Pull may be using GET or on
initiating OBSERVE.
g) Polling or Observing: Polling means finding from where new messages would
be available or whether new messages are available or updates are available or whether the
information needs to be refreshed or finding the status if the state information has changed
or not.
h) Push (Publish/Subscribe) Data : Push means a service that pushes the
messages or information regularly. Interested device or endpoint or potential receiver
receives these pushes. For example, a mobile service provider pushes the temperature and
location information regularly for the potential receivers (registered mobile services
subscribers) (PUT).
ii) CoAP-SMS and CoAP-MQ:
M2M or IoT device uses SMS quite frequently. SMS is identified as the transport protocol
for transmission of small data (up to 160 characters). It is used for communicating with a
GSM/GPRS mobile device. . CoAP-SMS and CoAP-MQ are two protocols drafted and
recommended by IETF.
a) CoAP-SMS : CoAP-SMS is a protocol when CoAP object uses IP as well as cellular
networks and uses SMS. It is an alternative to UDP-DTLS over ROLL for CoAP object
messages and when using cellular communication.
SMS is used instead of UDP + DTLS by a CoAP client or server. A CoAP client
communicates to a mobile terminal (MT) endpoint over the General Packet Radio
Service (GPRS), High Speed Packet Access (HSPA) or Long Term Evolution (LTE)
networks using CoAP-SMS protocol.
Following is the IETF recommended terminology for use:
• SMS-C: SMS service centre
• SMS-SP : SMS service provider
• CIMD: Computer interface to message distribution.
• MS: Mobile station at a cellular network functioning as CoAP client or CoAP sever.
• MT: Machine or IoT device or mobile terminal functioning as CoAP sever
• SMPP: Short message peer-to peer for CoAP-Data.
• UCP/UMI: Universal computer interface protocol/machine interface

ULNKUMAR, Dept. of MCA,ASCS


The CoAP-SMS features are as follows:
• An URI used as coap+sms:// in place of coap://. For example, URI may be coap+sms://
telNum/carLocationObject/latitude for latitude of location of a car after LocationObject
measures location parameters using the GPS.
• A CoAP message encodes with alphabets for SMS communication. An SMS message
consists of 160 characters in 7-bit encoding of a character. Maximum length for a CoAP
message is thus 140 B (= 160 × 7 bits/8 bits) when an SMS-C supports 8-bit encoding.
• CoAP endpoints have to work with a Subscriber Identity Module (SIM) card for SMS in
cellular networks. The points are addressed by using Mobile Station ISDN (MSISDN)
number.
• Does not support multi-casting.
• Two additional options are Response-to-URI-Host (RUH) and Response-to-URI-Port
(RUP) which make initiating CoAP client aware of the presence of the alternative
interface CIMD and SMPP and UCP/UMI.
• Data interchange sequences are as follows: An MS/CoAP client sends a SMS request
(SMS-SUBMIT) to SMS-C; SMS-C reports using SMS-SUBMIT-REPORT; SMS-C
sends SMS (SMS-DELIVER) to MS/CoAP server; the server reports using SMS-
DELIVERREPORT; and SMS-C sends SMS-STATUS-REPORT to the client.
b) CoAP-MQ: CoAP-MQ is a message queue protocol using a broker and Resources
Directory. Roles of CoAP endpoints have roles as a client and server. The data interchanges
between CoAP-MQ endpoints, CoAP-MQ clients, CoAP-MQ servers through CoAP-MQ broker
and its services.
The Following Are the features of CoAP-MQ :
• CoAP-MQ service Sending CoAP messages of one endpoint to another , queuing of
messages (store) by intermediate node (s).
• Forwarding only when it suits. for example, when the message recipient endpoint is
awake (not sleeping) or connected and alive.
• CoAP End Points Register with RD server for using Broker, (RD server advertises a
service).
• CoAP Endpoint Receives advertisements from Broker which may advertise service.
• CoAP endpoint May Permits implementation of sleeping end points and message queuing
for receiving on awaking of end-point.

ULNKUMAR, Dept. of MCA,ASCS


• CoAP-MQ Broker Functions as a server node capable of storing messages to and from
other nodes.
• CoAP-MQ Broker Performs a store-and-forward function between webclients and the
CoAP-MQ capable endpoints.
• CoAP Broker Matches subscriptions and publications in order to route messages to right
end-points.
• CoAP Broker enables the web client publishing of updates to the endpoint state.
• CoAP Broker Returns the last published value to web clients or other endpoints.
iii. MQTT: Message Queuing Telemetry Transport (MQTT) is an open-source protocol for
machine-to machine (M2M)/IoT connectivity. A version is MQTT-SN v1.2. Sensor networks
and non-TCP/IP networks, such as ZigBee can use the MQTT-SN. MQTT-SN is also a
publish/subscribe messaging protocol.
Figure shows messages interchange between M2M/IoT device objects (publisher and
subscriber) and web objects using an MQTT broker. Figure shows MQTT-broker subscription,
subscription match, store and forward, last good message retention and keep message alive
services. Device objects use MQTT Java, C or JavaScript library functions.

MQTT Broker does the following:

ULNKUMAR, Dept. of MCA,ASCS


1. Functions as a server node capable of storing messages from publishers and forwarding
them to the subscribing clients.
2. Receives topics from the publishers. Examples of topics are measured information of
ambient light conditions, traffic density, nearby parking space availability and waste
container status etc.
3. Performs a store-and-forward function, stores topics from publishers and forwards to
subscribers
4. Receives subscriptions from clients on the topics, matches subscriptions and publications
in order to route messages to right endpoints.

5. 5. Recovers subscriptions on reconnect after a disconnection, unless the client explicitly


disconnected.

6. 6. Finds client disconnection until DISCONNET message receives, keeps message alive
till explicit disconnection.

7. 7. Authentication by Username/Password in connect message and client security is


through SSL/TLS.

iv) XMPP: Stands for Extensible message presence protocol. XMPP is an XML-based
specification for messaging and presence protocols, a set of open technologies for instant
messaging, multi-party chat, voice and video calls, lightweight middleware, content
syndication, and generalized routing of XML data. XMPP is also an open-source protocol
recommended specification which is accepted by IETF.
XMPP can handle many of the core functions of a chat app including:
• Sending and receiving messages.
• Broadcasting a user's status.
• Managing a friends/contact list.
• And my personal favorite—blocking users from sending you messages.
XMPP Stanzas : XMPP transmits fragments of XML between two network endpoints.
Specifically, the XML fragments transmitted by XMPP, and used for basic communication,
are called stanzas. There are 3 types of stanzas used in XMPP.
• Presence stanza : the presence stanza is used to share the status of a network or user to
other users, networks, or servers.

ULNKUMAR, Dept. of MCA,ASCS


• Message stanza : The message stanza is used to share chat messages between users. A
message stanza has a type attribute that can have a few different values: chat, normal,
group chat, headline, and error.
• IQ stanza : An IQ stanza is XMPP's method of requesting and modifying data from
client to server. It's similar to HTTP's GET and POST request. Here’s an example IQ
stanza that is requesting the vCard (virtual contact file) of a specific user
The Following are the Features of XMPP :
1. XMPP allows for asynchronous messaging between users' devices. It means that two
users don't need to be online at the same time to exchange messages.
2. XMPP works by creating a persistent TCP (Transmission Control Protocol) connection
between a client and server or between one server and another server.
3. 3. XMPP is decentralized. This means that anyone can create their own XMPP server.
You can spin up your on XMPP server on-site.
4. 4. A key feature of XMPP's design is that it can be used to connect multiple types of
protocols such as XMPP -> SMS or SMS -> XMPP -> email. This is done using
something called gateways.

III) Web Connectivity for Connected devices Network Using Gateway,


SOAP, REST, HTTP RESTFUL AND WEBSOCKETS:
i) Communication Gateway: Communication gateway connects two application layers, one
at sender and the other at receiver. The gateway also enables use of two different protocols,
one at sender and the other at receiver ends. The gateway facilitates the communication
between web server using the TCP/IP protocol conversion gateway and IoT devices. It also
facilitates communication between the devices using CoAP client and server using HTTP.
The gateway provisions for one or more of the following functions:
 Connects the sender and receiver ends using two different protocols. For example,
IoT devices network maybe ZigBee network for connecting the devices. The network
then connects to the web server through a gateway.
 A gateway facilitates the communication between IoT devices and web server. For
example, (i) ZigBee to SOAP and IP or (ii) CoAP protocol conversion gateway for
RESTful HTTP.

ULNKUMAR, Dept. of MCA,ASCS


ii) SOAP: Simple Object Access (SOAP) is a W3C approved open-source protocol. SOAP is
a protocol for exchange of Structured data(objects) between applications using XML. It is
also a protocol for access to a web service. SOAP Provides a way to communication between
applications running on different OS , with different technologies and Programming
languages. It is also used for APIs for the web services and Service-Oriented Architecture
(SOA).
SOAP Building Blocks: The message in XML format contains four parts:
• Envelope: This specifies that the XML message is a SOAP message. A SOAP message
is an XML document containing a header and a body, both encapsulated within the
envelope.
• Header: This part is optional. When present, it can provide crucial information about the
applications.
• Body: This contains the actual message being transmitted. Faults are contained within the
body tags.
• Fault: This optional section contains the status of the application and any errors.

ULNKUMAR, Dept. of MCA,ASCS


iii) REST and HTTP RESTful: REST (Representational State Transfer) is a software
architectural style that was created to guide the design and development of the architecture for
the World Wide Web. REST is a coordinated set of constraints which are used during design of
software components in a distributed hypermedia, and the design depends on the characteristics
of stateless, client-server, cacheable communication using a protocol.
The Following are Functions of REST API And HTTP RESTful API:

 REST APIs don't store any information about a user's session. This means that every
request must provide complete data to be processed.
 REST APIs are cacheable, meaning that clients can store responses returned by
servers. This speeds up the response time for end-users.
 REST APIs use a layered system architecture, which limits component behavior to
improve application stability and security.
 REST APIs use a uniform interface, which defines a uniform contract and prohibits
the use of multiple interfaces within an API.
 REST APIs can send responses as executable codes, which should only run on-
demand.
 The RESTful API allows software developers to access a set of resources through
HTTP. This type of API encodes communication as JSON or XML with a content-
type header
 RESTful APIs use HTTP requests to access and use data. The data types that can be
used are GET, PUT, POST, and DELETE, which correspond to reading, updating,
creating, and deleting operations
iv) WebSockets: WebSocket is an IETF accepted protocol. Instant messaging and many
applications need bidirectional data exchanges over the same connection. WebSocket enables
bidirectional communication over a single TCP connection. It is a stateful protocol, which
means the connection between client and server will stay alive until it gets terminated by either
party (client or server). After closing the connection by either of the client or server, the
connection is terminated from both ends.
The following are the Features of WebSocket :

• Full-Duplex communication: WebSockets allow for simultaneous data transmission


and reception, which is ideal for real-time applications. .

ULNKUMAR, Dept. of MCA,ASCS


• Low Latency: WebSockets provide a near real-time connection between a client and a
server. (low latency).
• Stateful: WebSockets are stateful connections, meaning that the connection between a
client and a server remains constant.
• Data frames: WebSockets use data frames to send and receive information, which helps
to enhance security.
• TCP : WebSockets use TCP to establish a connection.
• Cloud Run : WebSockets can be implemented in a serverless environment like Google
Cloud Run to build scalable, real-time applications.

ULNKUMAR, Dept. of MCA,ASCS

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