Logical Design of IoT

In this article we discuss Logical design of Internet of things. Logical design of IoT system
refers to an abstract representation of the entities & processes without going into the low-
level specifies of the implementation. For understanding Logical Design of IoT, we describes
given below terms.

 IoT Functional Blocks

 IoT Communication Models
 IoT Communication APIs

IoT Functional Blocks

An IoT system comprises of a number of functional blocks that provide the system the
capabilities for identification, sensing, actuation, communication and management.

functional blocks are:

Device: An IoT system comprises of devices that provide sensing, actuation, monitoring and
control functions.

Communication: Handles the communication for the IoT system.

Services: services for device monitoring, device control service, data publishing services and
services for device discovery.

Management: this blocks provides various functions to govern the IoT system.

Security: this block secures the IoT system and by providing functions such as authentication
, authorization, message and content integrity, and data security.

Application: This is an interface that the users can use to control and monitor various aspects
of the IoT system. Application also allow users to view the system status and view or analyze
the processed data.
 IoT Communication Models

Request-Response Model

Request-response model is communication model in which the client sends requests to the
server and the server responds to the requests. When the server receives a request, it decides
how to respond, fetches the data, retrieves resource representation, prepares the response, and
then sends the response to the client. Request-response is a stateless communication model
and each request-response pair is independent of others.

HTTP works as a request-response protocol between a client and server. A web browser may
be the client, and an application on a computer that hosts a web site may be the server.

Example: A client (browser) submits an HTTP request to the server; then the server returns a
response to the client. The response contains status information about the request and may
also contain the requested content.
Publish-Subscribe Model

Publish-Subscribe is a communication model that involves publishers, brokers and

consumers. Publishers are the source of data. Publishers send the data to the topics which are
managed by the broker. Publishers are not aware of the consumers. Consumers subscribe to
the topics which are managed by the broker. When the broker receive data for a topic from
the publisher, it sends the data to all the subscribed consumers.

Push-Pull Model

Push-Pull is a communication model in which the data producers push the data to queues and
the consumers Pull the data from the Queues. Producers do not need to be aware of the
consumers. Queues help in decoupling the messaging between the Producers and Consumers.
Queues also act as a buffer which helps in situations when there is a mismatch between the
rate at which the producers push data and the rate rate at which the consumer pull data.

Exclusive Pair Model

Exclusive Pair is a bidirectional, fully duplex communication model that uses a persistent
connection between the client and server. Connection is setup it remains open until the client
sends a request to close the connection. Client and server can send messages to each other
after connection setup. Exclusive pair is stateful communication model and the server is
aware of all the open connections.

IoT Communication APIs

Generally we used Two APIs For IoT Communication. These IoT Communication APIs are:

 REST-based Communication APIs

 WebSocket-based Communication APIs

REST-based Communication APIs

Representational state transfer (REST) is a set of architectural principles by which you can
design Web services the Web APIs that focus on systems’s resources and how resource states
are addressed and transferred. REST APIs that follow the request response communication
model, the rest architectural constraint apply to the components, connector and data
elements, within a distributed hypermedia system. The rest architectural constraint are as
follows:

Client-server – The principle behind the client-server constraint is the separation of

concerns. for example clients should not be concerned with the storage of data which is
concern of the serve. Similarly the server should not be concerned about the user interface,
which is concern of the clien. Separation allows client and server to be independently
developed and updated.

Stateless – Each request from client to server must contain all the information necessary to
understand the request, and cannot take advantage of any stored context on the server. The
session state is kept entirely on the client.

Cache-able – Cache constraints requires that the data within a response to a request be
implicitly or explicitly leveled as cache-able or non cache-able. If a response is cache-able,
then a client cache is given the right to reuse that repsonse data for later, equivalent requests.
caching can partially or completely eliminate some instructions and improve efficiency and
scalability.

Layered system – layered system constraints, constrains the behavior of components such
that each component cannot see beyond the immediate layer with they are interacting. For
example, the client cannot tell whether it is connected directly to the end server or two an
intermediaryalong the way. System scalability can be improved by allowing intermediaries to
respond to requests instead of the end server, without the client having to do anything
different.

Uniform interface – uniform interface constraints requires that the method of

communication between client and server must be uniform. Resources are identified in the
requests (by URIsin web based systems) and are themselves is separate from the
representations of the resources data returned to the client. When a client holds a
representation of resources it has all the information required to update or delete the resource
you (provided the client has required permissions). Each message includes enough
information to describe how to process the message.

Code on demand – Servers can provide executable code or scripts for clients to execute in
their context. this constraint is the only one that is optional.

A RESTful web service is a ” Web API ” implemented using HTTP and REST principles.
REST is most popular IoT Communication APIs.
 HTTP methods
Uniform Resource Identifier (URI) GET PUT PATCH P
Create
Replace the in the c
List the URIs and
entire Not The new
Collection, such as perhaps other details
collection with generally URI is a
https://api.example.com/resources/ of the collection’s
another used automa
members.
collection. usually
the oper
Retrieve a
Replace the Not gen
representation of the Update the
addressed Treat th
addressed member addressed
Element, such as member of the membe
https://api.example.com/resources/item5
of the collection, member of
collection, or collecti
expressed in an the
if it does not right an
appropriate Internet collection.
exist, create it. new ent
media type.

WebSocket based communication API

Websocket APIs allow bi-directional, full duplex communication between clients and
servers. Websocket APIs follow the exclusive pair communication model. Unlike request-
response model such as REST, the WebSocket APIs allow full duplex communication and do
not require new coonection to be setup for each message to be sent. Websocket
communication begins with a connection setup request sent by the client to the server. The
request (called websocket handshake) is sent over HTTP and the server interprets it is an
upgrade request. If the server supports websocket protocol, the server responds to the
websocket handshake response. After the connection setup client and server can send
data/mesages to each other in full duplex mode. Websocket API reduce the network traffic
and letency as there is no overhead for connection setup and termination requests for each
message. Websocket suitable for IoT applications that have low latency or high throughput
requirements. So Web socket is most suitable IoT Communication APIs for IoT System.