BMS INSTITUTE OF TECHNOLOGY AND

MANAGEMENT
Avalahalli, Doddaballapura Main Road, Bengaluru - 560064
ASSESSMENT-2

Internet of Things
Name of the Course Course Code 15CS81
Technology
Information Science & th
31 Mar 2020
Branch & Semester Engineering. Deadline Date
VIII
Name of the Course Swetha M S
Max. Marks 30
Coordinator

Qn. Marks
No. Questions
1 Briefly explain the CoAP and its message format. 5M
.
Ans
Constrained Application Protocol (CoAP) is a specialized Internet Application Protocol for
constrained devices, as defined in RFC 7252. It enables those constrained devices called
"nodes" to communicate with the wider Internet using similar protocols. CoAP is designed
for use between devices on the same constrained network (e.g., low-power, lossy networks),
between devices and general nodes on the Internet, and between devices on different
constrained networks both joined by an internet. CoAP is also being used via other
mechanisms, such as SMS on mobile communication networks.

CoAP is a service layer protocol that is intended for use in resource-constrained internet
devices, such as wireless sensor network nodes. CoAP is designed to easily translate
to HTTP for simplified integration with the web, while also meeting specialized
requirements such as multicast support, very low overhead, and simplicity.[1][2] Multicast,
low overhead, and simplicity are extremely important for Internet of Things (IoT)
and Machine-to-Machine (M2M) devices, which tend to be deeply embedded and have much
less memory and power supply than traditional internet devices have. Therefore, efficiency is
very important. CoAP can run on most devices that support UDP or a UDP analogue.

The Internet Engineering Task Force (IETF) Constrained RESTful Environments Working
Group (CoRE) has done the major standardization work for this protocol. In order to make
the protocol suitable to IoT and M2M applications, various new functions have been added.
The core of the protocol is specified in RFC 7252; important extensions are in various stages
of the standardization process.

The smallest CoAP message is 4 bytes in length, if omitting Token, Options and Payload.
CoAP makes use of two message types, requests and responses, using a simple, binary, base
header format. The base header may be followed by options in an optimized Type-Length-
Value format. CoAP is by default bound to UDP and optionally to DTLS, providing a high
level of communications security.
Any bytes after the headers in the packet are considered the message body. The length of the
message body is implied by the datagram length. When bound to UDP, the entire message
MUST fit within a single datagram. When used with 6LoWPAN as defined in RFC 4944,
messages SHOULD fit into a single IEEE 802.15.4 frame to minimize fragmentation.
 CoAP Header
O
Of
c
fs
t 0 1 2 3
et
e
s
t
O
B 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
ct 0 1 2 3 4 5 6 7 8 9
it 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
et
V
3 Ty Token Request/Response
4 E Message ID
2 pe Length Code
R
6
8
4
Token (0 - 8 bytes)
9
12
6
1
16 2 Options (If Available)
8
1
20 6 1 1 1 1 1 1 1 1 Payload (If Available)
0

2 Explain the MQTT and PROFILES & COMPLIANCES 5M

Ans MQTT (MQ Telemetry Transport) is an open OASIS and ISO standard (ISO/IEC PRF
20922) lightweight, publish-subscribe network protocol that transports messages between
devices. The protocol usually runs over TCP/IP; however, any network protocol that
provides ordered, lossless, bi-directional connections can support MQTT. It is designed for
connections with remote locations where a "small code footprint" is required or the network
bandwidth is limited.

The MQTT protocol defines two types of network entities: a message broker and a number
of clients. An MQTT broker is a server that receives all messages from the clients and then
routes the messages to the appropriate destination clients. An MQTT client is any device
(from a micro controller up to a full-fledged server) that runs an MQTT library and connects
to an MQTT broker over a network.
Information is organized in a hierarchy of topics. When a publisher has a new item of data
to distribute, it sends a control message with the data to the connected broker. The broker
then distributes the information to any clients that have subscribed to that topic. The
publisher does not need to have any data on the number or locations of subscribers, and
subscribers, in turn, do not have to be configured with any data about the publishers.

If a broker receives a message on a topic for which there are no current subscribers, the
broker discards the message unless the publisher of the message designated the message as
a retained message. A retained message is a normal MQTT message with the retained flag set
to true. The broker stores the last retained message and the corresponding QoS for the
selected topic. Each client that subscribes to a topic pattern that matches the topic of the
retained message receives the retained message immediately after they subscribe. The broker
stores only one retained message per topic. This allows new subscribers to a topic to receive
the most current value rather than waiting for the next update from a publisher.When a
publishing client first connects to the broker, it can set up a default message to be sent to
subscribers if the broker detects that the publishing client has unexpectedly disconnected
from the broker.

Clients only interact with a broker, but a system may contain several broker servers that
 exchange data based on their current subscribers topics.A minimal MQTT control message
can be as little as two bytes of data. A control message can carry nearly 256 megabytes of
data if needed. There are fourteen defined message types used to connect and disconnect a
client from a broker, to publish data, to acknowledge receipt of data, and to supervise the
connection between client and server.

MQTT relies on the TCP protocol for data transmission. A variant, MQTT-SN, is used over
other transports such as UDP or Bluetooth.

MQTT sends connection credentials in plain text format and does not include any measures
for security or authentication. This can be provided by the underlying TCP transport using
measures to protect the integrity of transferred information from interception or duplication.
The default unencrypted MQTT port is 1883. The encrypted port is 8883.

3 Explain the types of Quality of Services offered in MQTT 5M

Ans
QoS 0 - at most once

The minimal QoS level is zero. This service level guarantees a best-effort delivery. There is
no guarantee of delivery. The recipient does not acknowledge receipt of the message and the
message is not stored and re-transmitted by the sender. QoS level 0 is often called “fire and
forget” and provides the same guarantee as the underlying TCP protocol.

QoS 1 - at least once

QoS level 1 guarantees that a message is delivered at least one time to the receiver. The
sender stores the message until it gets a PUBACK packet from the receiver that
acknowledges receipt of the message. It is possible for a message to be sent or delivered
multiple times.

The sender uses the packet identifier in each packet to match the PUBLISH packet to the
corresponding PUBACK packet. If the sender does not receive a PUBACK packet in a
reasonable amount of time, the sender resends the PUBLISH packet. When a receiver gets a
message with QoS 1, it can process it immediately. For example, if the receiver is a broker,
the broker sends the message to all subscribing clients and then replies with a PUBACK
packet.

If the publishing client sends the message again it sets a duplicate (DUP) flag. In QoS 1,
this DUP flag is only used for internal purposes and is not processed by broker or client. The
receiver of the message sends a PUBACK, regardless of the DUP flag.
 QoS 2 - exactly once

QoS 2 is the highest level of service in MQTT. This level guarantees that each message is
received only once by the intended recipients. QoS 2 is the safest and slowest quality of
service level. The guarantee is provided by at least two request/response flows (a four-part
handshake) between the sender and the receiver. The sender and receiver use the packet
identifier of the original PUBLISH message to coordinate delivery of the message.

When a receiver gets a QoS 2 PUBLISH packet from a sender, it processes the publish
message accordingly and replies to the sender with a PUBREC packet that acknowledges the
PUBLISH packet. If the sender does not get a PUBREC packet from the receiver, it sends the
PUBLISH packet again with a duplicate (DUP) flag until it receives an acknowledgement.

4 Differentiate between CoAP and MQTT 5M

Ans
Features CoAP MQTT

Constrained Application Message Queue

Full Form Protocol Telemetry Transport

Model used for Request-Response, Publish-

communication Subscribe Publish-Subscribe
RESTful Yes No
Preferably TCP, UDP
Preferably UDP, TCP can also can also be used
Transport layer be used. (MQTT-S).
Header Size 4 Bytes 2 Bytes

Number of message
types used 4 16

Messaging Asynchronous & Synchronous Asynchronous

Application Reliability 2 Levels 3 Levels

Not defined in the
Security IPSEC or DTLS standard

Bhoomika Mallesh
1BY17IS404