Module3:

Design Principles for Web Connectivity:

Introduction, Web Communication Protocols for
Connected Devices, Message Communication
Protocols for Connected Devices and Web
Connectivity for Connected-Devices Network using
Gateway, SOAP, REST, HTTP RESTful and
WebSockets.
 Terminologies:
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)
Publish/Subscribe (pubsub):
• 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; for example, measured
values of ambient light conditions, traffic density or traffic presence.
• 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.
• Publication may be for measured values, for state information or resources of one or more
types. Subscription is for a resource-type (or for a topic). A separate subscription is
required for each resource-type or topic.
• An example of resource type is measured values of ambient light condition in the
smart streetlights example. Another resource type is traffic presence or absence
on the street.
• Another resource type is lighting function report; functioning is proper or fault
exists in the light.
• Resource Directory:
• Resource directory (RD) maintains information and values for
each resource type.
• A resource of a resource type accesses from the RD using URI
for the resource.
• 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.
 Web Communication Protocols
For Connected Devices
• Data of connected devices routes over the web in two types of
communication environments. The environments are;
1. Constrained RESTful Environment (CoRE):
• 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, TCP and Internet Protocol (IP).
• Another constraint is data-routing when Routing over a network of Low
power and data Loss (ROLL).
• Another constraint is that the devices may sleep most of the time in low
power environment and awaken on an event or when required (on client
initiative)
• Devices’ connectivity may also break for long periods, have limited up
intervals in loss environment, and have limited data size.
2. Unconstrained Environment:
• Web applications use HTTP and RESTful HTTP for web client and web
server communication.
Figure: IoT or M2M devices local network connectivity and web connectivity in
constrained (above thick dotted line) and unconstrained RESTful HTTP (below thick
dotted line) environments using communication protocols.
 Constrained Application Protocol
IETF recommends Constrained Application Protocol (CoAP) which is for 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.
● 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,(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
cknowledgement, while non-confirmable means no acknowledgement is required.
• Integrates easily with the web using CoAP application cross-
protocol proxies.
• This is facilitated because HTTP and CoAP, both share the
REST model.
• A web client may not even be aware that it just accessed an
IoT device sensor resource or sent data to an IoT device
actuator resource.
● Use of REST: The access by a CoAP object or its resource is
thus using
– the URI
– a subset of MIME(Multipurpose Internet Mail Extensions) types
– a subset of response codes which are used for an HTTP object or
resource
Figure:(a) Direct and indirect accesses of CoAP client objects to a CoAP server, (b) CoAP client
access for lookup of object or resource using a resource directory, and
(c)CoAP client and server access using proxies
 Lightweight Machine-to-Machine Communication
Protocol
• It 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.
• Example of call to a system resource is calling an API for display menu or
network function in the system software (OS).
• 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.
• The protocol enables communication between LWM2M client at IoT device
and an LWM2M server at the M2M application and service capability layer.
The protocol is a compact one, meaning small header. It has an efficient data
model. It is generally used in conjunction with CoAP.
Figure:M2M devices local area network connectivity, and constrained devices
network connectivity with M2M applications and services using LWM2M
OMA standard specifications of LWM2M
 Message Communication Protocols for Connected Devices

CoAP-SMS and CoAP-MQ:

• CoAP-SMS:
• CoAP-SMS is a protocol when CoAP object uses IP as well as cellular
networks and uses SMS.
• 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.
The CoAP-SMS features are as follows:
• 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.
• A CoAP message is thus 70 (= 160 × 7 bits/16 bits) when an SMS-C
supports 16-bit encoding and multilingual alphabets. Concatenated short
messages can be up to 255B, provided the SMS-C supports this.
• 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.
• Authentication of a client by the server provides the security. MSISDN of the MS
and SIM based security is used during SMS data exchanges.
CoAP-MQ
• CoAP-MQ is a message queue protocol using a broker and RD.
• Roles of CoAP endpoints have roles as a client and server.
 MQTT Protocol
• Message Queuing Telemetry Transport (MQTT) is an open-
source protocol for machine-to machine (M2M)/IoT
connectivity.
Characteristics of MQTT
The MQTT has some unique features which are hardly found in other protocols.
Some of the features of an MQTT are given below:
 It is a machine to machine protocol, i.e., it provides communication between
the devices.
 It is designed as a simple and lightweight messaging protocol that uses a
publish/subscribe system to exchange the information between the client and
the server.
 It does not require that both the client and the server establish a connection at
the same time.
 It provides faster data transmission, like how WhatsApp/messenger provides a
faster delivery. It's a real-time messaging protocol.
 It allows the clients to subscribe to the narrow selection of topics so that they
can receive the information they are looking for.
Figure: Messages interchange between M2M/IoT device objects (publisher
and subscriber) and web objects (publisher and subscriber) using an MQTT
Broker
• MQTT 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. Examples of topics are measured
information of ambient light conditions, traffic density, nearby parking
space availability and waste container status.
• Performs a store-and-forward function, stores topics from publishers
and forwards to subscribers.
• Receives subscriptions from clients on the topics, matches
subscriptions and publications in order to route messages to right
endpoints.
• Recovers subscriptions on reconnect after a disconnection, unless the
client explicitly disconnected.
• Acts as a broker between the publisher of the topics and their
subscribers.
• Finds client disconnection until DISCONNET message receives,
keeps message alive till explicit disconnection.
•
• Retains the last-received message from a publisher for a new
connected subscriber on the same topic, when retain field in
the header is set.
• Authentication by Username/Password in connect message
and client security is through SSL/TLS. Security
considerations are same as of CoAP, web-linking and CoRE
resource directory.
• Support from Intelligent and business analyst server and other
servers through a MQTT server with a gateway.
 XML
• XML is an open-source IETF recommended language.
• XML is widely used for encoding messages and texts. A text
element in an XML document can correspond to the data, message,
alert, notification object, command, method or value of an entity.
• The type of encoded entity in an element.
• A tag may also associate an attribute(s) which is specified there
itself.
• The interpretation and use of the text within a tag pair (a tag and its
associated end tag) depends on the parser and associate application.
• The Parser uses XML file as input. The application uses the output
from the parser. The parser and application can be in Java, C# or any
other programming language.
 XMPP
• XMPP is an XML-based specification for messaging and presence
protocols.
• XMPP enables interoperable communication: for example, Google
Talk.
• XMPP enables IMs between many users as it uses presence-
notifications and chat features.
• Chat room is an application, in which all those who have subscribed
(meaning persons and objects initiating chatting and messaging to
one another at the same time) are provided a room-like view and use
the IMs among themselves.
Features of XMPP are:
• XMPP uses XML.
• XML elements are sent in the open-ended stream within the
tag <stream> andcorresponding end tag </stream>.
• Three basic types of XMPP elements are:
– message
– presence
– iq (information/query, request/response)
• Extensibility to constrained environment messaging and
presence protocols as well asIP network messaging.
• Extensibility of request-response (client-server) architecture
to iq (information through querying), PubSub messaging, Chat
room MUC messaging and other architecture (where group of
people exchange information when present in a chat room),
decentralised XMPP server