UNIT 4

IOT ARCHITECTURE AND PROTOCOLS

PRUDHVI KIRAN P
Assistant Professor, CSE - IoT Dept.
R. V. R. & J. C. College of Engineering
UNIT - 4 [ 12 Periods ]
MQTT Publish-Subscribe: Architecture, Packet Structure and Communication Format
MQTT-SN: Architecture, Topology, Transparent and Aggregating Gateways, Gateway
advertisement and Discovery
CoAP: Architecture, Message Formats, Usage Examples
Other Protocols: AMQP, XMPP, SOAP, REST, WebSocket
Identification Protocols: EPC, ucode, URI
Device Management Protocols: TR-069, OMA-DM
Semantic Protocols: JSON-LD, Web Thing Model

SUBJECT CODE - CO 224

CLASS DETAILS - IoT IV SEM - MARCH 2023
FACULTY DETAILS - PRUDHVI KIRAN P, Asst. Prof., CSE (IoT), RVR&JC College of Engineering
QUESTION BANK - UNIT 4 [Assignment Questions - 2, 7, 8]
1. Discuss about MQTT-PS with neat diagrams representing it's architecture and packet structure.
2. Discuss about MQTT-SN architecture and differentiate transparent and aggregating gateways.
3. Discuss about CoAP with neat architecture and also explain it's the packet structure in detail.
4. Discuss about AMQP in detail with neat architecture diagram.
5. Discuss about SOAP and WebSocket protocols in detail with neat architecture diagrams.
6. Discuss about REST in detail with neat architecture diagram.
7. Discuss about EPC and ucode in detail.
8. Discuss various aspects of TR-069 in detail.
9. Discuss about JSON-LD in detail.
END
 MQTT (Message Queuing Telemetry Transport) is an OASIS (Organization for the Advancement of
Structured Information Standards) standard messaging protocol for the Internet of Things (IoT).
It is designed as an extremely lightweight - publish/subscribe messaging transport that is ideal
for connecting remote devices with a small code footprint and minimal network bandwidth.
 MQTT today is used in a wide variety of industries, such as automotive, manufacturing,
telecommunications, oil and gas, etc. It was created by Dr. Andy Stanford-Clark and Arlen Nipper
in 1999, as a cost-effective and reliable way to connect & monitoring devices used in the oil and
gas industries.
 The protocol operates over internet protocols TCP/IP which allow bidirectional communications
that are structured and seamless. MQTT-SN v1.2, also known as MQTT for Sensor Networks
(MQTT-SN), is a version of the protocol designed for embedded systems on non-TCP/IP networks.
FAMOUS 'MQTT BROKER' PLATFORMS
MQTT- PS ARCHITECTURE
4.1. MQTT Publish-Subscribe: Architecture
 The Publish-Subscribe is a TCP/IP based messaging pattern that decouples the clients that send
messages (publishers) from the clients that receive messages (subscribers) by allowing them to
communicate without having direct connections or knowledge of each other's existence.
 The essence of MQTT's Publish-Subscribe pattern is that, there exists a middleman role called a
Broker is responsible for routing and distributing all messages. Publishers send messages with
topics to the Broker, and subscribers subscribe to topics from the Broker to receive messages of
interest.
 In MQTT, topics and subscriptions cannot be pre-registered or created. As a result, the broker
cannot predict how many subscribers will be interested in a particular topic. When a publisher
sends a message, the broker will only forward it to the subscribers that are currently subscribed
to the topic. If there are no current subscribers for the topic, the message will be discarded.
The MQTT Publish-Subscribe pattern has four main components:
1. Publisher
2. Subscriber
3. Broker
4. Topic
1. Publisher
The publisher is responsible for publishing messages to a topic. It can only send data to one topic at
a time and does not need to be concerned about whether the subscribers are online when
publishing a message.
2. Subscriber
The subscriber receives messages by subscribing to a topic and can subscribe to multiple topics at
once.
3. Broker
The broker is responsible for receiving messages from publishers and forwarding them to the
appropriate subscribers. In addition, the broker also handles requests from clients for connecting
and disconnecting, subscribing and unsubscribing.
4. Topic
MQTT routes messages based on topics. A topic is typically levelled and separated with a forward
slash ‘/’ between the levels, this is similar to URL paths. For example, a topic could be
sensor/1/temperature. Multiple subscribers can subscribe for the same topic, and the broker will
forward all messages on that topic to these subscribers. Multiple publishers can also send messages
to the same topic, and the broker will route these messages in the order they are received, to the
subscribed clients. Topic is case sensitive and should be minimum 1 character length.
In the MQTT publish-subscribe pattern, a client can function as a publisher, a subscriber, or both.
When a client publishes a message, it sends it to the broker, which then routes the message to all
subscribed clients on that topic. If a client subscribes to a topic, it will receive all the messages that
the broker forwards for that topic.
ARCHITECTURE

EMQX is an Open-source MQTT broker with a high-performance real-time message processing

engine, powering event streaming for IoT devices at massive scale. As the most scalable MQTT
broker, EMQX can help you connect any device, at any scale.
PACKET STRUCTURE
PUBLISH SUBSCRIBE

Packet Id - The packet identifier uniquely identifies a message, Topic Name - Hierarchically
structured string with forward slashes as delimiters, Quality of Service Level (QoS) - Quality of the
message. There are three levels: 0, 1 and 2. Retain Flag - This defines whether the message is saved
by the broker as the last known good value for a specified topic. Payload - This is the actual content
of the message. DUP flag - The flag indicates that the message is a duplicate and was resent
because the intended recipient (client or broker) did not acknowledge the original message.
About Quality of Service Levels (QoS)
QoS Level Publisher Subscriber
0: Will send a message only once. Might receive or might not receive the message.
at most once
Will send a message at least once as long as an It is likely to receive the message at least once (it
1: acknowledgement is received or the command is possible that the message can be received
at least once to end the transmission is received. more than once).
2: Will only send a message once. Will only receive the message once.
exactly once

COMMUNICATION FORMAT
The MQTT uses the command and the command
acknowledgment format, which means that each
command has an associated acknowledgment. As
shown in the above figure that the connect
command has connect acknowledgment, subscribe
command has subscribe acknowledgment, and The MQTT publish/subscribe mechanism can easily meet our
publish command has publish acknowledgment. communication needs of one-to-one, one-to-many, and many-
to-one. Its flexibility makes it also well-suited for use in
This mechanism is similar to the handshaking industries besides the IoT field, such as webcasts and mobile
mechanism as in TCP protocol. push notifications.
COMMUNICATION FORMAT - PUBLISHER AND SUBSCRIBE
4.2. MQTT-SN: Architecture
 MQTT-SN stands for "MQTT for Sensor Networks" is aimed at embedded devices on non-TCP/IP
networks, such as Zigbee. MQTT-SN is a extension/light weight version of the MQTT Publish
Subscribe protocol with capability to support the Sensor and Actuator solutions beyond the
reach of TCP/IP infrastructure. MQTT-SN works over the User Datagram Protocol (UDP)
unlike MQTT which uses TCP/IP.
MQTT-SN Vs MQTT - PS;
 MQTT and MQTT-SN are different from each other. MQTT is a protocol which is designed to be
light weight for M2M, but it needs TCP/IP stack to operate. But if the sensor nodes cannot hold
the TCP/IP stack then here comes MQTT-SN which does not depend on TCP/IP for it to operate.
In MQTT-SN, the SN or Sensor Network in the protocol name indicates that it is specifically
designed for sensor networks.
 As sensor nodes are specifically made with limited processing capabilities and limited amount
of storage, so these sensor nodes cannot have TCP/IP stack with themselves because TCP/IP
protocol stack is too heavy to be handled by such tiny sensor nodes due to big payload, retry
mechanism, time to live for the packets etc.
How MQTT-SN is different from MQTT?
 MQTT-SN is designed to be as close as possible to MQTT, but is adapted to the particular
behaviour of wireless communication network such as low bandwidth, high link failures, short
message length etc.
 MQTT-SN is optimized for the implementation on low cost, battery-operated devices with
limited processing and storage resources.
 MQTT-SN provides a sleeping client mechanism. This feature enables clients to shut
themselves down and save power for a while.
 MQTT-SN supports topic ID instead of topic name. First client sends a registration
request with topic name and topic ID (8 bytes) to the broker. After the registration is
accepted, client uses topic ID to refer the topic name. This saves media bandwidth and
device memory - it is quite expensive to keep and send topic names like
home/livingroom/socket2/meter in memory for each publish message.
 MQTT-SN needs a bridge to translate MQTT-SN messages into MQTT messages. For that, MQTT-
SN introduce gateways in its network. Gateway translate between MQTT-SN and MQTT and
exchange messages between device and mqtt broker. And there is a mechanism that called
gateway discovery, which enables device to find gateways automatically.
ARCHITECTURE & TOPOLOGY

Scaling is the main problem faced by MQTT-PS; with the rapidly increasing IoT devices, there is tons
of data moving and more power consumption too. MQTT-SN avoids all these potential problems of
scaling. MQTT-SN is intended to cooperate well with MQTT-PS.
ARCHITECTURE & TOPOLOGY
ARCHITECTURE & TOPOLOGY
MQTT-SN has three components:
1. MQTT-SN Clients
2. Broker
3. MQTT-SN Gateway
4. MQTT-SN forwarder.
1. MQTT-SN Clients
 Client can function as a publisher, a subscriber, or both; The publisher is responsible for
publishing messages to a topic. It can only send data to one topic at a time and does not need to
be concerned about whether the subscribers are online when publishing a message.
 The subscriber receives messages by subscribing to a topic and can subscribe to multiple topics
at once.
2. Broker
 The broker is responsible for receiving messages from publishers and forwarding them to the
appropriate subscribers. In addition, the broker also handles requests from clients for connecting
and disconnecting, subscribing and unsubscribing.
3. MQTT-SN Gateway
It is a translation layer that converts
MQTT Packets to MQTT-SN packets
and vice versa. Gateway can be a
separate entity or it can be a part of
the Broker.
4. MQTT-SN Forwarder
When the clients cannot be connected directly to the MQTT-SN Gateway. This can happen if the
Gateway is not attached to the same network. Forwarder receives the message from clients and
forward it to Gateway, unchanged. In the same way it receives the messages from the gateway
and forward them to clients, unchanged.
TRANSPARENT AND AGGREGATING GATEWAYS
Transparent MQTT-SN Gateway involves only translation. The broker has to maintain concurrent
MQTT Connections with Broker. Aggregating MQTT-SN Gateway involves not only translation but also
collection, filtering and processing of client messages. Here only one MQTT connection is seen
between the Gateway and Broker. But it is hard to implement. In Transparent Gateway, each MQTT-
SN connection has a corresponding MQTT connection. Where as in aggregating gateway, multiple
MQTT-SN connections share a single MQTT connection.

MQTT-SN MQTT BROKER MQTT-SN

CLIENTS CLIENTS

TRANSPARENT GATEWAY AGGREGATING GATEWAY

Aggregating Gateway is good for servers that do not support the great number of concurrent
connections.
GATEWAY ADVERTISEMENT AND DISCOVERY
MQTT-SN has two below mentioned mechanisms for a client to discover an MQTT-SN Gateway,
both mechanisms require the use of multicast messages.
1. Client search/Gateway Discovery
2. Gateway Advertisement
1. Client search/Gateway Discovery
 Client search means, the client can search for a gateway rather than wait for an advertise packet.
This process includes:
A. Send search Gateway Message (SEARCHGW)
B. Wait for Gateway or client response (GWINFO)
C. Update Gateway table
 Both clients and gateways can respond to the SEARCHGW message. A Gateway will respond to
this message using a GWINFO message which contains the Gateway ID only. Another client will
respond to this message using a GWINFO message which contains the Gateway ID and the
Gateway IP Address. Gateway table at client contains the gateway information.
2. Gateway Advertisement
 The gateway can also advertise using the ADVERTISE multicast message at intervals which is
determined by the configuration file.
 The advertise packet contains the, the gateway id and advertise duration in seconds. On receipt
of the advertise packet the client has the necessary information to connect to the Gateway. The
client knows from the duration in the advertise packet, how often it should receive an advertise
packet and should then mark a gateway as inactive if it fails to receive an advertise after a
certain time. It can then fall back to another gateway in it’s list.
 Generally the client will use a Gateway search to locate a gateway on starting. It will then listen
for Gateway advertise messages to keep the gateway table updated. Client can receive multiple
Gateway advertisements, and store the details of Gateways in it's Gateway table.
4.3. CoAP: Architecture
 Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with
constrained nodes and constrained networks in the Internet of Things. CoAP is designed to
enable simple, constrained devices to join the IoT. For communication, MQTT uses the publish-
subscribe prototype and CoAP uses a request-response prototype.
 With the help of this protocol, the COAP package is shared between various client nodes, which
are directed by the COAP server.
 CoAP and HTTP follow the same working procedure. However, CoAP attains its functionality via
asynchronous transactions (using UDP).

 HTTP is document centric. But in loT all we want is to send data, not documents. That's the
point to note while comparing CoAP with HTTP.
ARCHITECTURE
 CoAP has a client-server architecture and supports 1:1
communication. Like MQTT, CoAP protocol also has two
components.
1. Client
2. Server

 Clients can make requests to servers to serve data in the stated

format. The Servers then interpret the request and send data
accordingly. The sensor nodes are usually the servers when we use
CoAP. This makes it necessary for sensor modules to handle receiving
and translation of messages coming from the client. The client can be
any resource that needs the sensor information.
CoAP CLIENT - SERVER
CoAP Working Instance
CoAP uses REST (Representational State Transfer) architectural
 Similar to HTTP, CoAP uses style, where data and functionality are considered resources and
client/server model with are accessed using Uniform Resource Identifiers (URIs), typically
request/response messages. links on the Web.
 It supports built-in discovery
of services and resources,
Uniform resource identifiers
(URIs).
 The CoAP sends a request
message requesting an action
to the resource (identified by
a URI) hosted on a server,
using request message
(code). The server responds
to this request by using the
response message that
contains the Response Code,
and possibly some resource CoAP - FUNCTIONAL ARCHITECTURE
representation.
 CoAP works for devices in the same network types and also enables data transmission, to and
fro, for the general internet-enabled nodes and network-connected devices.
 The WWW (World Wide Web) and the constraints ecosystem are the 2 foundational elements of
the CoAP protocol architecture. Here, the server monitors and helps in communication happening
using CoAP and HTTP while proxy devices bridge the existing gap for these 2 ecosystem, making
the communication smoother.
CoAP is compatible with 4 types of information exchange;
1. Acknowledgments (ACK) confirm the completion or failure of an event.
2. Confirmable (CON) are the messages that are resent on time out until the confirmation of
successful sending doesn’t arrive.
3. Reset (RST) messages are empty, with confirmable as their nature.
4. Non-confirmable (NON) information is just sent and has no guarantee of successful delivery.
There is no acknowledgment of success either.
CoAP Security Aspects
 As stated before, CoAP uses UDP to transport information. CoAP relies on UDP security aspects to
protect the information. As HTTP uses TLS over TCP, CoAP uses Datagram TLS (DTLS) over UDP.
DTLS provides equivalent security guarantees, as HTTP.
MQTT & CoAP

Communication model is many-many in MQTT, where as in CoAP, the communication model is

one-one. MQTT is ideal for Event-oriented operations, while CoAP is viable for state transfer
information.
 CoAP MQTT

MQTT stands for Message query telemetry

1 CoAP stands for Constrained Application Protocol. transport.

2 CoAP uses the Request-Response model. MQTT uses the Publish-Subscribe model.

3 CoAP uses
Protocol ).
UDP protocol(User Datagram MQTT uses TCP protocol(Transmission Control
Protocol).

4 The communication model is One-to-one. The communication model is Many-to-many.

The security type is DTLS(Datagram Transport

5 Layer Security). The security type is SSL/TLS.

6 Effectiveness in LLN is excellent. Effectiveness in LLN is low.

7 Use both
messages.
Asynchronous and Synchronous Uses only Asynchronous messages.

8 C0AP header size 4 bytes. MQTT header size 2 bytes.

MESSAGE FORMAT

 Version (Ver) - 2-bit unsigned integer that identifies the CoAP version. Currently it must be set
to 01.
 Type (T) - 2-bit unsigned integer that indicates the message type: Confirmable (0), Non-
Confirmable(1), Acknowledgement (2), or Reset (3).
 Token Length (TKL) - 4-bit unsigned integer that stands for the length of the Token field. Tokens
are unique values used to match requests to responses.
 Code - 8 bit unsigned integer, that represents the Token code, it is a request or response code.
REQUEST CODES RESPONSE CODES

1. GET method retrieves the information of the resource

identified by the request URI
2. POST method requests that the representation enclosed in
the request be processed. It usually results in a new resource
being created or the target resource being updated.
3. PUT method requests that the resource identified by the
request URI be updated or created with the enclosed
representation.
4. DELETE method requests that the resource identified by the
request URI be deleted.
 Message ID - 16 bits Unique identifier for the packet. Used for duplicate detection.
 Token - used to match responses to requests independently from the underlying messages.
 Options - Contains extra metadata.
 Payload Marker - Indicates the beginning of message payload.
 Payload - Message payload.
Two Message Exchange Patterns of CoAP

a) Piggybacked response b)Separate response

 In Piggyback response, when the client send the request and not yet received the reply from
server, client may keep sending the requests continually, it may not be the ideal thing to do.
 With separate response, server notifies client about receipt of the request message. This will
increase processing time but help in avoiding unnecessary retransmissions.
CoAP USAGE EXAMPLES
4.4.1 AMQP
 AMQP (Advanced Message Queuing Protocol) is a messaging protocol that enables conforming
client applications to communicate with conforming messaging middleware brokers.
 Messaging brokers receive messages from publishers (applications that publish them, also
known as producers) and route them to consumers (applications that process them).
 Messages are published to exchanges, which are often compared to post offices or mailboxes.
Exchanges then distribute message copies to queues (0 or more) using rules called bindings.
Then the broker either deliver messages to consumers subscribed to queues, or consumers
fetch/pull messages from queues on demand.
 Networks are unreliable and applications may fail to process messages therefore the AMQP
model has a notion of message acknowledgements: when a message is delivered to a consumer
the consumer notifies the broker, either automatically or as soon as the application developer
chooses to do so. When message acknowledgements are in use, a broker will only completely
remove a message from a queue when it receives a “successful receive acknowledgement”
notification for that message (or group of messages).
 Overall, the goal of AMQP is to enable message passing through broker services over TCP/IP
connections.
ARCHITECTURE

EXCHANGE
QUEUE

PUBLISHERS AMQP BROKER SUBSCRIBERS

How does AMQP Exchanges Work?
After receiving messages from publishers (i.e. clients), the
exchanges process them and route them to one or more queues.
The type of routing performed depend on the type of the
exchange, which is referred to, using rules called bindings. There
are currently four types of patters followed by exchanges;
1. Direct Exchange
A direct exchange delivers messages to queues based on the
message routing key. A direct exchange is ideal for the unicast
routing of messages. They can be used for multicast routing as well.
Here is how it works:
• A queue binds to the exchange with a routing key K
• When a new message with routing key R arrives at the direct
exchange, the exchange routes it to the queue if K = R
• If multiple queues are bound to a direct exchange with the same
routing key K, the exchange will route the message to all queues
for which K = R
2. Fanout Exchange
 A fanout exchange routes messages to all of the queues that are bound to it and the routing key
is ignored. If N queues are bound to a fanout exchange, when a new message is published to that
exchange a copy of the message is delivered to all N queues. Fanout exchanges are ideal for the
broadcast routing of messages.
Example:
Massively multi-player online (MMO) games can use it for leaderboard updates or other global
events.
3. Topic Exchange
 Topic exchanges route messages to one or many queues based on matching between a message
routing key and the pattern that was used to bind a queue to an exchange.
Example:
• Distributing data relevant to specific geographic location, for example, points of sale.
• Background task processing done by multiple workers, each capable of handling specific set of
tasks.
4. Header Exchange
 A headers exchange is designed for routing on multiple attributes that are more easily expressed
as message headers than a routing key. Headers exchanges ignore the routing key attribute.
Instead, the attributes used for routing are taken from the headers attribute. A message is
considered matching if the value of the header equals the value specified upon binding.
4.4.2 XMPP
 XMPP stands for Extensible Messaging and Presence Protocol. It is a communication protocol,
based on Extensible Markup Language (XML), for real-time communication.
 It supports a wide range of applications including presence, collaboration, instant messaging,
multi-party chat etc. It is maintained by XSF (XMPP Standards Foundation). This protocol is
mostly used by instant messaging applications like WhatsApp.
Let’s dive into each character of word XMPP:
1. X : It means extensible. XMPP is a open source project which can be changed or extended
according to the need.
2. M : XMPP is designed for sending messages in real time. It has very efficient push mechanism
compared to other protocols.
3. P : It determines whether you are online/offline/busy. It indicates the state.
4. P : XMPP is a protocol, that is, a set of standards that allow systems to communicate with each
other.
 In XMPP, a client with a unique name communicates with another client with a unique name
through an associated server, using the internet's Transmission Control Protocol (TCP).
ARCHITECTURE

 The entire processing of XMPP relies upon the client-server architecture that interests message
transmission to the server first and then to the clients.
 To find out which client should receive the message, the XMPP server utilizes the unique ID of
the receiver. The unique ID or Jabber ID is very much comparable to an email address with
negligible changes. Example: [email protected]/resource is the format for the Jabber ID.
XMPP Features
 Asynchronous Push Messaging
With XMPP, continual and asynchronous message delivery is achievable. With this, we mean
message dispatch in a row, not waiting for the receiver or sender reply, and not necessitating the
user to be online to accept the message.
 Client-Server Architecture
This is the core architecture that XMPP follows. In this architecture, XMPP disseminates only a small
fraction of XML elements. This portative XML element will first reach to the server and then to the
user.
 Persistent TCP Connections
Originally, XMPP can transmit the data or designate a connection over TCP only. Connection built
over here is invariant and doesn’t demand re-establishment whenever a new message is
transmitted.
 Decentralized Hosting
With decentralized hosting, we refer to having no central authority controlling the server. Anyone
can maintain, run, and even maintain the XMPP servers. Additionally, freedom to set up the servers
on either cloud or premise is also granted
 Gateways
One another very distinguishing feature of XMPP is that it offers gateways for numerous chats and
messaging protocols. It’s compatible with many protocols and can link to the networks at length.
Few XMPP Protocol usage Examples
1. WhatApp is built using a proprietary XMPP.
2. The amazing chat capability of Zoom is all because of XMPP.
3. For instant push notification delivery, Apple uses XMPP both in the iPhone and Mac.
4.4.3 SOAP
 SOAP stands for Simple Object Access Protocol is a network platform/protocol used in a web
service to exchange or communicate data between two different machines on a network.
 It uses the XML (eXtensible Markup Language) format of data to transfer messages over the
HTTP protocol. In Web services, SOAP allows the user request to interact with other
programming languages; in this way, it provides a way to communicate between applications
running on different platforms (Operating Systems), i.e. SOAP was designed to be OS and
Platform independent and It is built on top of HTTP which is installed in most systems.
SOAP MESSAGE REQUEST

SOAP MESSAGE RESPONSE

Each message can be thought of as an envelope with some data information inside.
SOAP BUILDING BLOCK
1. SOAP Envelope:
Envelope is used to define the start and end of the SOAP
message. It contains the details of the SOAP message. It is an
important element of the XML documents.
2. SOAP Header:
It is an optional element in which the header contains the
credentials information such as authorization, authentication,
etc. is used during the processing of a SOAP message.
3. SOAP Body:
It is an important element of the SOAP message that contains
request/response information in the XML format. It defines the
actual content of the message to be sent between the client and
the webserver.
4. SOAP Fault:
The SOAP Fault element is an optional element used to display an error message encountered during
the transmission of a SOAP message. It holds the status of SOAP messages and errors.
 A SOAP-based messaging system will describe services and functions that can be accessed by a
client only if it closely follows the same rules (e.g. matching data types) set by the server. In
other words, SOAP presents a tightly-coupled contract between client and server.
 As a protocol, SOAP offers a complete suite of features for developers to implement as they see
fit, including error-checking, data integrity and security, success/retry logic, and end-to-end
reliability. These features are optionally applied with the use of SOAP extensions such as WS-
Security, WS-AtomicTransaction, and WS-ReliableMessaging.
4.4.4 REST
 REST, or REpresentational State Transfer, is an architectural style for providing standards
between computer systems on the web, making it easier for systems to communicate with each
other.
 In the REST architectural style, the implementation of the client and the implementation of the
server can be done independently without each knowing about the other. This means that the
code on the client side can be changed at any time without affecting the operation of the server,
and the code on the server side can be changed without affecting the operation of the client.
 Systems that follow the REST paradigm are stateless, meaning that the server does not need to
know anything about what state the client is in and vice versa. In this way, both the server and
the client can understand any message received, even without seeing previous messages.
 In the REST architecture, clients send requests to retrieve or modify resources, and servers send
responses to these requests.
 Instead of using XML to make a request like in SOAP, REST (usually) relies on a simple URL. In
some situations you must provide additional information, but most web services using REST rely
exclusively on using the URL approach. REST can use four different HTTP methods (GET, POST,
PUT, and DELETE) to perform tasks.
1. The GET is used to read (or retrieve) a representation of a resource.
2. The POST is most often utilized to create new resources.
3. The PUT is used for updating the capabilities. However, PUT can also be used to create a
resource in few cases.
4. The DELETE is used to delete a resource identified by a URI.
 REST has been employed throughout the software industry and is a widely accepted set of
guidelines for creating stateless, reliable web APIs.
You can think of an API as a mediator between the users or clients and the resources or web
services they want to get. It’s also a way for an organization to share resources and information
while maintaining security, control, and authentication - determining who gets access to what.
Another advantage of an API is that you don’t have to know the specifics of caching - how your
resource is retrieved or where it comes from.
REST defines 6 architectural constraints which make any web service - a truly RESTful API;
1. Uniform interface
2. Client - server
3. Stateless
4. Cacheable
5. Layered system
6. Code on demand
1. Uniform interface
 While the client and the server change in different ways, it’s important that the API can still
facilitate communication. To that end, REST APIs impose a uniform interface that can easily
accommodate all connected software.
 In most cases, that interface is based on the HTTP protocols as it has the advantage of being
widely known and used on the Internet.
2. Client - Server
 An API’s job is to connect two pieces of software without limiting their own functionalities. The
client and server can update and evolve in different directions without having an impact on the
quality of their data exchange.
3. Statelessness
 For an API to be stateless, it has to handle calls independently of each other. Each API call has to
contain the data and commands necessary to complete the desired action.
 An example of a non-stateless API would be if, during a session, only the first call has to contain
the API key, which is then stored server-side. The following API calls depend on that first one since
it provides the client’s credentials.
 In the same case, a stateless API will ensure that each call contains the API key and the server
expects to see proof of access each time.
4. Cacheable
 The client has the option to locally store certain pieces of data for a predetermined period of
time. When they make a request for that data, instead of the server sending it again, they use the
stored version.
5. Layered system
 To keep the API easy to understand and scale, RESTful architecture dictates that the design is
structured into layers that operate together.
 With a clear hierarchy for these layers, executing a command means that each layer does its
function and then sends the data to the next one. Connected layers communicate with each other.
6. Code on demand
 The concept is to allow code or applets to be sent through the API and used for the application.
As you can imagine, unknown code from a shady source could do some damage. Another
drawback is that the code has to be in the appropriate programming language for the application,
which isn’t a practical case.
 The upside is that “code on demand” can help the client implement their own features on the go,
with less work being necessary on the API or server. In essence, it permits the whole system to be
much more scalable and agile.
REST APIs allow you to perform CRUD (create, read, update, and delete) operations between a client
and a server. It is the most common type of API, and almost 80% of all public APIs are REST.
Best Practices for REST API Security;
• Implement Authentication
• Use Transport layer Security(TLS) for protecting the information by encrypting it
• Validate API Parameters
• Request Rate Limiting
• Use Pagination to limit the number of resources client can access in a single request
4.4.5 WebSocket
 The WebSocket protocol enables, full-duplex - bidirectional communication between a web
client and a web server over an underlying TCP connection.
 It is a stateful protocol, which means the connection between client and server will keep alive
until it is terminated by either party (client or server). After closing the connection by either of
the client and server, the connection is terminated from both ends. When the connection is
established and alive the communication takes place using the same connection channel until it
is terminated.
 After client-server handshaking, the client-server decide on a new connection to keep it alive, this
new connection will be known as WebSocket. Once the communication link establishment and
the connection are opened, message exchange will take place in bidirectional mode until
connection persists between client-server.
 Both HTTP and WebSocket are employed for application communication; WebSocket is a
bidirectional protocol and HTTP is a unidirectional protocol functioning above the TCP.
 HTTP uses http:// and https://. HTTP is a stateless protocol. In HTTP when a user sends a request
to the server this request goes in the form of HTTP or HTTPS, after receiving a request, server
send the response to the client, each request is associated with a corresponding response, after
sending the response the connection gets closed, each HTTP or HTTPS request establish the new
connection to the server every time and after getting the response the connection gets
terminated by itself.
 WebSocket starts from ws:// or wss://. WebSocket, is a stateful protocol. In WebSocket,
connection between client and server will keep alive until it is terminated by either party (client
or server). After closing the connection by either of the client and server, the connection is
terminated from both ends.
Real-time web application uses a web socket to show the data at the client end, which is
continuously being sent by the backend server. In WebSocket, data is continuously
pushed/transmitted into the same connection which is already open, that is why WebSocket is faster
and improves the application performance.
For e.g. in a trading website, for displaying the price fluctuation and movement data is
continuously pushed by the backend server to the client end by using a WebSocket channel.
IDENTIFICA
PROTOCO
TION
LS
4.5.1 EPC
 Electronic Product Code (EPC) is a universal identifier that aims to render a unique identity to
every possible physical object of the world. EPCs are mostly encoded on RFID (Radio Frequency
Identification) tags that are used to check identities of objects like inventory, assets and people,
and also track them.
 An Electronic Product Code (EPC) is a 96-bit (24 Hexadecimal Chars) numerical code used to
identify different commodities. An EPC is basically an identifier but it has many more functions.
For instance, an electronic product code contains numbers that can be used to track different
information about the products, such as manufacturing date, products origin, and destination,
etc. An electronic product code is very similar to a bar code but with greater utility.
 The EPC structure is defined in the EPCglobal Tag Data Standard, which is a freely available
standard. GS1's EPC Tag Data Standard (TDS) defines the Electronic Product Code (EPC), including
its correspondence to other globally used codes.
 GS1, a nonprofit organization based in New Jersey, sets and manages the information standards
that go into EPC codes. Businesses can purchase EPCs from GS1 or from other barcode
companies. If you sell your products to or through other retailers, it’s important to make sure
those retailers will accept third-party barcodes on their sales platforms.
 1 hexadecimal digit = 4 bits
Format of EPC

1. Header - A 8-bit number that shows the length, type, structure, version, and partitioning
scheme.
2. EPC Manager Number - A 28-bit number that indicates company manufacturer.
3. Object Class - A-24 bit number that identifies product types.
4. Serial Number - A 36-bit unique number that identifies each product instance.
GS1 barcodes/GTINs are necessary for most online and traditional retailers including Amazon, eBay,
Alibaba, Google, Carrefour, Tesco and Walmart. GS1 barcodes are scanned over 6 billion times each
day, driving commerce around the globe. For acquiring EPC and other services related to it, visit
https://www.gs1.org/
EPC Services
4.5.2 ucode
 ucode is an ID to identify various types of objects and concepts. This ID is a number and has no
meaning in itself. The objects that can be identified by ucode, for instance, fruits such as an
apple and an orange, a home appliance, each component of a home appliance, and an abstract
concept such as the record of these items. Ucode makes it possible to track the production area
and nutritional information of foodstuff, its current location, status, history, etc. In this way,
ucode can identify an “object” and “concept” anytime, anywhere.
 ucode is assigned to an “object” to identify it, and the device that stores ucode is called a “ucode
tag.” There are many types of “ucode tags” such as barcodes, smart IC cards, and active/passive
RFID chips. An “object” is not limited to movable objects but can be immovables such as
buildings and concept such as location.
 YRP Ubiquitous Networking Laboratory (JAPAN) has developed the ucode. The ucode system uses
128 bit code (32 Hexadecimal Chars) for unique naming of things, so there are
340282366920938463463374607431768211455 or 3.4 x 10^38 different codes.
 If more codes are needed, they can be added in chunks of 128 bits. Each ucode is unique, there
can - or at least should - not be another ucode with exactly the same number.
 http://www.uidcenter.org/ facilitates existing ucode search and issuing new ucode (free of
cost) and other information about ucode.
 1 hexadecimal digit = 4 bits
ucode created for Object (https://rvrjcce.ac.in/),
00001C000000000000010002DF50A9DB, the number is can be searched in ucode
repository at http://www.uidcenter.org/

ucode can be created by entering your email ID at http://www.uidcenter.org/create by using ucode

issue service. Then a mail will be received from ucode, with further steps, guiding us to associate a
object with that code.
ucode Process Architecture:
Steps to acquire data from ucode:
A. First, the ucode from an ucode tag/qr/barcode using a mobile phone (or any other device) is
read.
B. The camera of the phone can be used to read a matrix code containing the ucode.
C. Then, the mobile phone inquires the ucode resolution server - via internet connection - about
the code.
D. The ucode resolution server returns the location of the provided ucode information on ucode
information server based on the ucode read. Finally, the mobile phone connects to the
information server and acquires contents and services.
The ucode server architecture is similar to the familiar Internet DNS resolution service. The root
server is maintained by uID Center in Tokyo.
4.5.3. URI
 Uniform Resource Identifier (URI), a character string that helps in identifying a resource on the
Internet.
 Similar to the real world, the web world is also loaded with lots of information and documents
which are distributed worldwide. In order to reach the specific document on the web, we need a
unique identifier. URIs and their generic syntax are defined by Internet Engineering Task Force
(IETF)
Types of URI
1. Uniform Resource Locator (URL)
2. Uniform Resource Name (URN)
1. Uniform Resource Locator (URL)
 It gives the location of the object in a disciplined and structured format. This enables a unique
identification of the object. But any change in the location of the object, due to say a server
change, cannot be carried out automatically.
 URLs are a subset of URIs. All URLs are URIs, but all URIs are not URLs. For Example,
http://webpage.com/download.jpg can be considered as both a URL and URI and
mailto:[email protected] is a URI but not URL.
2. Uniform Resource Name (URN)
 Maybe the URN acronym is less popular than URL and URI, but it belongs to the same family. It
stands for Uniform Resource Name, and its scope is to identify resources in a permanent way,
even after that resource does not exist anymore.
 Unlike a uniform resource locator (URL), which cannot work if the content is moved, a URN is
always able to track the resource of certain data on the Web, hence resolving a frequent issue of
moving of data.
URL & URN format
URN URN represents the URN’s scheme
specification. Namespace is a identifier
which is registered with IANA (Internet
Assigned Numbers Authority) and Identifier
precisely identifies the particular object.

URL Protocol represents the scheme to be used

to access the resource on the Internet. The
Resource - Location identifies the location of
specific resource in the host that the web
client wants to access.
 ISBN number is a URI
designed to name a book
in a unique manner and at
worldwide level.

All the URNs and URLs are URIs, and while the URN only identifies resources without telling you
how to access them, the URL do tell you where and how to access the desired resource.
Basic requirements for Uniform Resource Identifier:
1. Uniqueness: Uniform Resource Identifier should give every resource available on the Internet
or worldwide web a unique distinguishing identity.
2. Universality: It should be able to identify or address every available resource on the Internet.
3. Extensibility: New resources which are not yet a part of the worldwide web should be able to
be identified by a unique new Uniform Resource Identifier.
4. Fixability: This Identifier should be editable and changeable. It should be shareable and
printable.
MANAGEM
PROTOCO
ENT
LS
4.6.1 TR-069
 Technical Report 069 (TR-069) is a technical specification of the Broadband Forum (non-profit
industry consortium dedicated to developing broadband network specifications) that defines an
application layer protocol for remote management and provisioning of customer-premises
equipment (CPE) connected to an Internet Protocol (IP) network.
 TR-069 uses the CPE WAN Management Protocol (CWMP) which provides support functions for
auto-configuration, software or firmware image management, software module management,
status and performance managements, and diagnostics.
 A TR-069 client is a software application that allows service providers and equipment
manufacturers to manage, configure, and update their customers' network-connected devices
remotely.
 TR-069 clients are important for both service providers and equipment manufacturers because
they provide a simple and efficient way to manage a large number of devices remotely.
 By using a TR-069 client, service providers can quickly and easily configure new devices, update
firmware, monitor the status & performance, tests speed and troubleshoot problems without
having to dispatch a technician to the customer's premises. Note that, the configuration is
managed by a central server called an auto-configuration server (ACS).
TR - 069 Provisioning Session
 The connection between the device and the ACS is not permanent. The device establishes the
connection with the ACS only at specific points in time. It usually lasts several seconds - just
enough to exchange all necessary messages between CPE and the ACS. This short exchange of
messages is called a provisioning session. The provisioning session is divided into a few phases;
1. Session initialization - The session is always initialized by the device that connects to the ACS.
2. Authentication - The ACS must verify a username and a password provided by the device to
continue the session.
3. Device identification - Devices are identified on the basis of information sent during
initialization of the provisioning session.
4. Tasks execution on the device - When the device is identified and its communication part ends,
a key phase of the session starts the ACS orders various tasks on the device.
5. Session closure - When all planned tasks have been ordered, the device closes the session. Any
further tasks need initialization of a new session.
The session can be started only by the device, not by ACS. However, the ACS can send a request to
establish connection, that is Connection Request, informing the device about a need of connecting
to the server.
 According to information of The Broadband Forum, there are more than 1 billion devices with TR-
069 around the world. Since its creation, the protocol was mostly used in modems, routers and
gateways. But over time, new devices that support CWMP emerged, such as IPTV and VoIP
phones.
 Various other technical formats that involve remote device management, such as Home
Gateway Initiative (HGI) and the WiMAX Forum, for example, endorse the use of TR-069 as a
communication protocol.
 Along with device management, TR-069 is also used to collect data that can be used in business
analysis, for example, detecting active users to whom additional offers can be made.
TR - 069 Security
 TR-069 is a scalable, flexible and secure model that provides the high degree of security required
while remaining simple to use. TR-069 provides several mechanisms that guarantee robust
security. Device authentication uses username and password. SSL (Secure socket layer)/TLS
(Transport layer security) certificates can be used to mutually verify ACS' and device's identities.
TR - 069 Working Architecture

OSS (Operational Support Systems) is responsible for the day-to-day operations (monitoring,
controlling, analyzing and managing of a network), while BSS (Business Support Systems) provides
the necessary tools and services to manage customer relationships.
4.6.2 OMA-DM
 OMA Device Management is a device management protocol specified by the Open Mobile
Alliance (OMA) Device Management (DM) Working Group and the Data Synchronization (DS)
Working Group. The current approved specification of OMA DM is version 1.2.1.
 OMA DM specification is designed for management of mobile devices such as mobile phones,
PDAs, and tablet computers.
Device management is intended to support the following uses:
1. Provisioning - Configuration of the device (including first time use), enabling and disabling
features
2. Device Configuration - Allow changes to settings and parameters of the device.
3. Software Upgrades - Provide for new software and/or bug fixes to be loaded on the device,
including applications and system software.
4. Fault Management - Report errors from the device, query about status of device.
OMA DM was originally developed by The SyncML Initiative Ltd, an industry consortium formed by
many mobile device manufacturers. The SyncML Initiative got consolidated into the OMA umbrella
as the scope and use of the specification was expanded to include many more devices and support
global operation.
 OMA-DM was designed with mobile devices in mind. Consequently, its unique benefits include
its ability to work alongside small footprint devices where storage space and memory may be
constrained, such as IoT constrained devices.
 It also handles low bandwidth situations well and offers watertight security in the form of
authentications and challenges. In spite of many similar standards and protocols, it is frequently
by service providers to remotely set parameters and troubleshoot terminals as and when
necessary.
Technically, the OMA DM protocol uses XML for data exchange. The device management takes
place by communication between a server (which is managing the device) and the client (the device
being managed).
OMA DM is designed to support and utilize any number of data transports such as:
A. Physically over both wireline (USB, RS-232) and wireless media (GSM, CDMA, IrDA, or
Bluetooth)
B. Transport layers implemented over any Wireless Session Protocol (WSP), like HTTP or similar
transports.
The communication is initiated by the OMA DM server, asynchronously, using any of the methods
available such as a WAP Push or SMS. The initial message from server to client is said to be in the
form of a notification, or alert message.
OMA - DM Security
 The communication protocol is a request-response protocol. Authentication and challenge of
authentication are built-in to ensure the server and client are communicating only after proper
validation. The server and client are both stateful, meaning a specific sequence of messages are
to be exchanged only after authentication is completed to perform any task.
 Like TR - 069, in OMA - DM also device authentication uses username and password and also SSL
(Secure socket layer)/TLS (Transport layer security) certificates used to mutually verify devices
identities.
OMA DB Working Architecture
 SEMAN
PROTOCO
TIC
LS
4.7.1 JSON-LD
 JSON (JavaScript Object Notation) is a text-based data exchange format. It is a collection of key-
value pairs where the key must be a string type, and the value can be of any of the following
types:
• Number
• String
• Boolean
• Array
• Object (when you do not know at compile time what data type the variable might point to)
• null
 In the JSON data format, the keys must be enclosed in double quotes. The key and value must be
separated by a colon (:) symbol. There can be multiple key-value pairs. Two key-value pairs must
be separated by a comma (,) symbol. No comments (// or /* */) are allowed in JSON data.
Here is how some simple JSON data looks:
{
"name": "Alex C",
"age": 2,
"city": "Houston"
}
 Valid JSON data can be in two different formats; A collection of key-value pairs enclosed by a pair
of curly braces {...}. You saw this as an example above. A collection of an ordered list of key-value
pairs separated by comma (,) and enclosed by a pair of square brackets [...], see the example
[ below:
{
"name": "Alex C",
"age": 2,
"city": "Houston"
},
{
"name": "John G",
"age": 40,
"city": "Washington"
},
{
"name": "Bala T",
"age": 22,
"city": "Bangalore"
}
]
JSON-LD
 JSON-LD stands for JavaScript Object Notation for Linked Data. JSON-LD is JSON, plus the linked
data aspect. Linked data is about making links, so that a person or machine can explore the web of
data. With linked data, when you have some of it, you can find other, related, data.
 JSON-LD allows you to express relationships between entities using URLs as identifiers and linking
them together in a graph-like structure. This makes it easier to connect data from different
sources and enrich it with contextual information.
JSON-LD achieves this by introducing a specific structure and vocabulary for representing linked data.
It uses a special "@context" property that defines the terms and their meanings in the JSON-LD
document.

WEBSITE A WEBSITE B WEBSITE C

4.7.2 Web Thing Model
 Web Thing Model, which represents a standardized way to provide information on a virtual or
physical device, known as a Thing.
 Web Thing Model is a cookbook for integrating Things to the Web and in particular to HTTP,
WebSocket, JSON and JSON-LD.
 It was built to give recommendations in 4 main areas: Protocols, Best Practices, Resources and
Data Model and Semantic Extensions.
 The Web Thing Model is a core concept within the Web of Things framework. It defines a
standardized way to represent and interact with IoT devices and their functionalities on the web.
 The idea is to create a common language for describing IoT devices and their capabilities, making
it easier for developers to build applications that can work with various types of IoT devices
seamlessly.
A Web Thing model typically includes the following components:
Thing Description
 It provides general metadata about the Web Thing, such as its name, description, and supported
protocols. It also includes links to further resources and endpoints for interacting with the device.
 Properties
Properties represent the state or attributes of the Web Thing. They can be read-only or read-write
and provide information about the current status of the device. Examples of properties could
include temperature, humidity, on/off status, or any other relevant information.
 Actions
Actions define the operations or commands that can be performed on the Web Thing. They allow
you to control the device or trigger specific functionalities.
Actions may have input parameters and return values, enabling bidirectional communication
between the client and the device.
 Events
Events are notifications or updates emitted by the Web Thing to inform clients about changes in its
state. Clients can subscribe to events to receive real-time updates. For example, a motion sensor
might emit an event when it detects movement.
Web Thing models are typically written in the Web of Things (WoT) Thing Description format, which
is a JSON-LD (JavaScript Object Notation for Linked Data) document, which is easier to understand
and process by both humans and machines.
END OF UNIT 4