A detailed documentation on internet protocols at present happening of internet of things applications and a bit comparison of protocols using basic requirements

1. An Assessment of Internet of Things
Protocols for Resource-Constrained
Applications

2. Abstract
With the resource constraints of Internet of Things (IoT) devices, performance and energy
efficiency have become an important IoT software design consideration while minimizing
resource usages. To provide efficient communication for resource-constrained applications,
several IoT protocols have been introduced, and yet there are few existing guidelines to help
the programmer choose an appropriate communication protocol. To address this limitation,
we evaluate five different communication protocols including CoAP, MQTT, MQTT-SN,
WebSocket, and TCP. Our result can help IoT application programmers make informed
decision when choosing communication protocols for their applications.

3. 1. INTRODUCTION
1.1 Protocol
The Internet protocols are the world’s most popular open-system (nonproprietary)
protocol suite because they can be used to communicate across any set of interconnected
networks and are equally well suited for LAN and WAN communications. The Internet
protocols consist of a suite of communication protocols, of which the two best known are the
Transmission Control Protocol (TCP) and the Internet Protocol (IP). The Internet protocol
suite not only includes lower-layer protocols (such as TCP and IP), but it also specifies
common applications such as electronic mail, terminal emulation, and file transfer. This
chapter provides a broad introduction to specifications that comprise the Internet protocols.
Discussions include IP addressing and key upper-layer protocols used in the Internet.
Specific routing protocols are addressed individually in Part 6, Routing Protocols.
Internet protocols were first developed in the mid-1970s, when the Defense Advanced
Research Projects Agency (DARPA) became interested in establishing a packet-switched
network that would facilitate communication between dissimilar computer systems at
research institutions. With the goal of heterogeneous connectivity in mind, DARPA funded
research by Stanford University and Bolt, Beranek, and Newman (BBN). The result of this
development effort was the Internet protocol suite, completed in the late 1970s. TCP/IP later
was included with Berkeley Software Distribution (BSD) UNIX and has since become the
foundation on which the Internet and the World Wide Web (WWW) are based.
The Internet Protocol (IP) is a network-layer (Layer 3) protocol that contains addressing
information and some control information that enables packets to be routed. Along with the
Transmission Control Protocol (TCP), IP represents the heart of the Internet protocols.
IP has two primary responsibilities: providing connectionless, best-effort delivery of
datagrams through an internetwork and providing fragmentation and reassembly of
datagrams to support data links with different maximum-transmission unit (MTU) sizes.

4. fig 1.1 OSI Model
1.2 IP Address Format
fig 1.2

5. 2 Transmission Control Protocol (TCP)
The TCP provides reliable transmission of data in an IP environment. TCP
corresponds to the transport layer (Layer 4) of the OSI reference model. Among the services
TCP provides are stream data transfer, reliability, efficient flow control, full-duplex
operation, and multiplexing. With stream data transfer, TCP delivers an unstructured stream
of bytes identified by sequence numbers. This service benefits applications because they do
not have to chop data into blocks before handing it off to TCP. Instead, TCP groups bytes
into segments and passes them to IP for delivery.TCP offers reliability by providing
connection-oriented, end-to-end reliable packet delivery through an internetwork. It does this
by sequencing bytes with a forwarding acknowledgment number that indicates to the
destination the next byte the source expects to receive. Bytes not acknowledged within a
specified time period are retransmitted. The reliability mechanism of TCP allows devices to
deal with lost, delayed, duplicate, or misread packets. A time-out mechanism allows devices
to detect lost packets and request retransmission.
TCP offers efficient flow control, which means that, when sending acknowledgments back to
the source, the receiving TCP process indicates the highest sequence number it can receive
without overflowing its internal buffers. Full-duplex operation means that TCP processes can
both send and receive at the same time. Finally, TCP’s multiplexing means that numerous
simultaneous upper-layer conversations can be multiplexed over a single connection.
fig 2.1
Illustrates the fields and overall format of a TCP packet

6. 2.1 TCP Packet Field Descriptions
The following descriptions summarize the TCP packet fields illustrated in Figure
• Source Port and Destination Port—Identifies points at which upper-layer source and
destination processes receive TCP services.
• Sequence Number—Usually specifies the number assigned to the first byte of data in the
current message. In the connection-establishment phase, this field also can be used to identify
an initial sequence number to be used in an upcoming transmission
.
• Acknowledgment Number—Contains the sequence number of the next byte of data the
sender of the packet expects to receive.
• Data Offset—Indicates the number of 32-bit words in the TCP header.
• Reserved—Remains reserved for future use.
• Flags—Carries a variety of control information, including the SYN and ACK bits used for
connection establishment, and the FIN bit used for connection termination.
• Window—Specifies the size of the sender’s receive window (that is, the buffer space
available for incoming data).
• Checksum—Indicates whether the header was damaged in transit.
• Urgent Pointer—Points to the first urgent data byte in the packet.
• Options—Specifies various TCP options.
• Data—Contains upper-layer information.
2.3 User Datagram Protocol (UDP)
The User Datagram Protocol (UDP) is a connectionless transport-layer protocol
(Layer 4) that belongs to the Internet protocol family. UDP is basically an interface between
IP and upper-layer processes. UDP protocol ports distinguish multiple applications running
on a single device from one another. Unlike the TCP, UDP adds no reliability, flow-control,
or error-recovery functions to IP. Because of UDP’s simplicity, UDP headers contain fewer
bytes and consume less network overhead than TCP. UDP is useful in situations where the
reliability mechanisms of TCP are not necessary, such as in cases where a higher-layer
protocol might provide error and flow control.UDP is the transport protocol for several well-
known application-layer protocols, including Network File System (NFS), Simple Network
Management Protocol (SNMP), Domain Name System (DNS), and Trivial File Transfer
Protocol (TFTP).The UDP packet format contains four fields, as shown in Figure 30-11.
These include source and destination ports, length, and checksum fields.

7. 3. MQTT (Message Queuing Telemetry Transport)
MQTT (Message Queuing Telemetry Transport) is a lightweight messaging protocol
that provides resource-constrained network clients with a simple way to distribute telemetry
information. The protocol, which uses a publish/subscribe communication pattern, is used for
machine-to-machine (M2M) communication and plays an important role in the Internet of
Things (IoT).
MQTT allows devices to send (publish) information about a given topic to a server that
functions as an MQTT message broker. The broker then pushes the information out to those
clients that have previously subscribed to the client's topic. To a human, a topic looks like a
hierarchical file path. Clients can subscribe to a specific level of a topic's hierarchy or use a
wildcard character to subscribe to multiple levels.
MQTT is a good choice for wireless networks that experience varying levels of latency due
to occasional bandwidth constraints or unreliable connections. Should the connection from a
subscribing client to the broker get broken, the broker will buffer messages and push them
out to the subscriber when it is back online. Should the connection from the publishing client
to the broker be disconnected without notice, the broker can close the connection and send
subscribers a cached message with instructions from the publisher.
MQTT was created by Dr. Andy Stanford-Clark of IBM and Arlen Nipper of Arcom (now
Eurotech) in 1999 as a cost-effective, reliable way to connect monitoring devices used in the
oil and gas industries with remote enterprise servers.
fig 3.1
MQTT Model

8. When challenged with finding a way to push data from pipeline sensors in the desert
to off-site SCADA (supervisory control and data acquisition) systems, they decided upon a
TCP/IP-based publish/subscribe topology which would be event-driven to keep satellite link
transmission costs down. Although MQTT is still closely associated with IBM, it is now an
open protocol that is overseen by the Organization for the Advancement of Structured
Information Standards (OASIS). While the name suggests it, MQTT is not part of the
original IBM MQ series, but as of v7.1, it is available in WebSphere MQ.
Facebook currently uses MQTT for their messenger app, not only because the protocol
conserves battery power during mobile phone-to-phone messaging, but also because in spite
of inconsistent Internet connections across the globe, the protocol allows messages to be
delivered efficiently in milliseconds.
Amazon Web Services (AWS) supports MQTT, as well as HTTP, for connecting remote
devices to the Amazon IoT cloud.
3.1 MQTT Fixed Header
The message header for each MQTT command message contains a fixed header. The
table below shows the fixed header format.
Byte 1
Contains the Message Type and Flags (DUP, QoS level, and RETAIN) fields.
Byte 2
(At least one byte) contains the Remaining Length field.
The fields are described in the following sections. All data values are in big-endian
order: higher order bytes precede lower order bytes. A 16-bit word is presented on the
wire as Most Significant Byte (MSB), followed by Least Significant Byte (LSB).
3.2 How MQTT works
An MQTT session is divided into four stages: connection, authentication,
communication and termination. A client starts by creating a TCP/IP connection to the broker
by either using a standard port or a custom port defined by the broker's operators. When
connecting, it is important to recognize that the server might continue an old session if
provided with a re-used client identity. The standard ports are 1883 for non-encrypted
communication and 8883 for encrypted communication using SSL/TLS. During the

9. SSL/TLS handshake, the client validates the server certificate to authenticate the server. The
client may also provide a client certificate to the broker during the handshake which the
broker can use to authenticate the client. While not specifically part of the MQTT
specification, it has become customary for brokers to support client authentication with
SSL/TLS client-side certificates. Because MQTT aims to be a protocol for resource-
constrained devices, SSL/TLS might not always be an option and in some cases, might not be
desired. In such cases, authentication is presented as a clear-text username and password that
is sent by the client to the server as part of the CONNECT/CONNACK packet sequence.
Some brokers, especially open brokers published on the Internet, will accept anonymous
clients. In such cases, the username and password is simply left blank. MQTT is called a
lightweight protocol because all messages have a small code footprint. Each message
consists of a fixed header (2 bytes), an optional variable header, a message payload that is
limited to 256 MB of information and a Quality of Service (QoS) level. The three different
Quality of Service levels determine how the content is managed by the MQTT protocol.
Although higher levels of QoS are more reliable, they have more latency and bandwidth
requirements so subscribing clients can specify the highest QoS level they would like to
receive. The simplest QoS level is Unacknowledged Service. This QoS level uses a
PUBLISH packet sequence; the publisher sends a message one time to the broker and the
broker passes the message one time to subscribers. There is no mechanism in place to make
sure the message has been received correctly and the broker does not save the message.
fig 3.2 MQTT QOS Model

10. This QoS level may also be referred to as "at most once," "QoS0" or "fire and
forget."The second QoS level is Acknowledged Service. This QoS level uses a
PUBLISH/PUBACK packet sequence between the publisher and its broker, as well as
between the broker and subscribers. An acknowledgement packet verifies that content has
been received and a retry mechanism will send the original content again if an
acknowledgement is not received in a timely manner, and this may result in the subscriber
receiving multiple copies of the same message. This QoS level may also be referred to as "at
least once" or "QoS1."The third QoS level is Assured Service. This QoS level delivers the
message with two pairs of packets. The first pair is called PUBLISH/PUBREC and the
second pair is called PUBREL/PUBCOMP, and the two pairs ensure that regardless of the
number of retries made, the message will only be delivered once. This QoS level may also be
referred to as "exactly once" or "QoS2."During the communication phase, a client can
perform publish, subscribe, unsubscribe and ping operations. The publish operation sends a
binary block of data (the content) to a topic that is defined by the publisher.
MQTT supports message BLOBS up to 256 MB in size. The format of the content is
application specific. Topic subscriptions are made using a SUBSCRIBE/SUBACK packet
pair. Un-subscription is similarly performed using a UBSUBSCRIBE/UNSUBACK packet
pair. Topic strings form a natural topic tree by the use of a special delimiter character, the
forward slash (/). A client can subscribe to (and unsubscribe from) entire branches in the
topic tree by the use of special wildcard characters. There are two: A single-level wild-card
character, the plus-character (+); and a multi-level wild-card character, the hash-sign (#). A
special topic character, the dollar character ($), excludes a topic from any root wild-card
subscriptions. Typically, the $ is used to transport server-specific or system messages. The
fourth operation a client can perform during the communication phase is to ping the broker
server using a PINGREQ/PINGRESP packet sequence which roughly translates to ARE
YOU ALIVE/YES I AM ALIVE. This operation has no other function than to maintain a live
connection and ensure the TCP connection has not been shut down by a gateway or router.
When a publisher or subscriber desires to terminate an MQTT session, it sends a
DISCONNECT message to the broker and then closes the connection. This is called a
graceful shutdown because it provides the client with the ability to easily reconnect by
providing its client identity and resuming where it left off. Should the disconnect happen
suddenly without time for a publisher to send a DISCONNECT message, the broker may
send subscribers a message from the publisher that the broker has previously cached. The
message, which is called a last will and testament, provides subscribers with instructions for
what to do if the publisher "dies" unexpectedly.

11. 4. Constrained Application Protocol (CoAP)
The interaction model of CoAP is similar to the client/server model of HTTP.
However machine-to-machine interactions typically result in a CoAP implementation acting
in both client and server roles. A CoAP request is equivalent to that of HTTP and is sent by
a client to request an action (using a Method Code) on a resource (identified by a URI) on a
server. The server then sends a response with a Response Code; this response may include a
resource representation.
Unlike HTTP, CoAP deals with these interchanges asynchronously over a datagram-oriented
transport such as UDP. This is done logically using a layer of messages that supports
optional reliability (with exponential back-off). CoAP defines four types of messages:
Confirmable, Non-confirmable, Acknowledgement, Reset. Method Codes and Response
Codes included in some of these messages make them carry requests or responses. The basic
exchanges of the four types of messages are somewhat orthogonal to the request/response
interactions; requests can be carried in Confirmable and Non-confirmable messages, and
responses can be carried in these as well as piggybacked in Acknowledgement messages.
One could think of CoAP logically as using a two-layer approach, a CoAP messaging layer
used to deal with UDP and the asynchronous nature of the interactions, and the
request/response interactions using Method and Response Codes (see Figure ). CoAP is
however a single protocol, with messaging and request/response as just features of the CoAP
header.
fig 4.1 Abstract Layering of CoAP

12. 4.1 Messaging Model
The CoAP messaging model is based on the exchange of messages over UDP
between endpoints. CoAP uses a short fixed-length binary header (4 bytes) that may be
followed by compact binary options and a payload. This message format is shared by
requests and responses. Each message contains a Message ID used to detect duplicates and
for optional reliability. (The Message ID is compact; its 16-bit size enables up to about 250
messages per second from one endpoint to another with default protocol parameters.)
Reliability is provided by marking a message as Confirmable (CON). A Confirmable
message is retransmitted using a default timeout and exponential back-off between
retransmissions, until the recipient sends an Acknowledgement message (ACK) with the
same Message ID (in this example, 0x7d34) from the corresponding endpoint; When a
recipient is not at all able to process a Confirmable message (i.e., not even able to provide a
suitable error response), it replies with a Reset message (RST) instead of an
Acknowledgement (ACK).
fig 4.2 Reliable message transmission fig 4.3 Unreliable message transmission
A message that does not require reliable transmission (for example, each single measurement
out of a stream of sensor data) can be sent as a Non-confirmable message (NON). These are
not acknowledged, but still have a Message ID for duplicate detection (in this example,
0x01a0) When a recipient is not able to process a Non-confirmable message, it may reply
with a Reset message (RST). As CoAP runs over UDP, it also supports the use of multicast
IP destination addresses, enabling multicast CoAP requests. The proper use of CoAP
messages with multicast addresses and precautions for avoiding response congestion. Several
security modes are defined for CoAP ranging from no security to certificate-based security.

13. 4.2 Request/Response Model
CoAP request and response semantics are carried in CoAP messages, which include
either a Method Code or Response Code, respectively. Optional (or default) request and
response information, such as the URI and payload media type are carried as CoAP options.
A Token is used to match responses to requests independently from the underlying messages.
(Note that the Token is a concept separate from the Message ID.) A request is carried in a
Confirmable (CON) or Non-confirmable (NON) message, and, if immediately available, the
response to a request carried in a Confirmable message is carried in the resulting
Acknowledgement (ACK) message. This is called a piggybacked response. (There is no need
for separately acknowledging a piggybacked response, as the client will retransmit the
request if the Acknowledgement message carrying the piggybacked response is lost.) Two
examples for a basic GET request with piggybacked response , one successful, one resulting
in a 4.04 (Not Found) response.
fig 4.4 Two GET Requests with Piggybacked Responses
If the server is not able to respond immediately to a request carried in a Confirmable
message, it simply responds with an Empty Acknowledgement message so that the client can
stop retransmitting the request. When the response is ready, the server sends it in a new
Confirmable message (which then in turn needs to be acknowledged by the client). This is
called a "separate response". If a request is sent in a Non-confirmable message, then the
response is sent using a new Non-confirmable message, although the server may instead send
a Confirmable message.

14. Fig 4.5 A GET Request with a Separate Response and Response Carried in Non-confirmable messages
CoAP makes use of GET, PUT, POST, and DELETE methods in a similar manner to
HTTP, with the semantics. (Note that the detailed semantics of CoAP methods are "almost,
but not entirely unlike" [HHGTTG] those of HTTP methods: intuition taken from HTTP
experience generally does apply well, but there are enough differences that make it
worthwhile to actually read the present specification.) Methods beyond the basic four can be
added to CoAP in separate specifications. New methods do not necessarily have to use
requests and responses in pairs. Even for existing methods, a single request may yield
multiple responses, e.g., for a multicast request or with the Observe option [OBSERVE]. URI
support in a server is simplified as the client already parses the URI and splits it into host,
port, path, and query components, making use of default values for efficiency. Response
Codes relate to a small subset of HTTP status codes with a few CoAP-specific codes added.
4.3 Message Format
CoAP is based on the exchange of compact messages that, by default, are transported
over UDP (i.e., each CoAP message occupies the data section of one UDP datagram). CoAP
may also be used over Datagram Transport Layer Security (DTLS). It could also be used
over other transports such as SMS, TCP, or SCTP, the specification of which is out of this
document’s scope. CoAP messages are encoded in a simple binary format. The message
format starts with a fixed-size 4-byte header. This is followed by a variable-length Token
value, which can be between 0 and 8 bytes long. Following the Token value comes a
sequence of zero or more CoAP

15. Options in Type-Length-Value (TLV) format, optionally followed by a payload that takes up
the rest of the datagram.
fig 4.6 message format
The fields in the header are defined as follows:
Version (Ver.): 2-bit unsigned integer. Indicates the CoAP version number. Implementations
of this specification MUST set this field to 1 (01 binary). Other values are reserved for future
versions. Messages with unknown version numbers MUST be silently ignored.
Type (T): 2-bit unsigned integer. Indicates if this message is of type Confirmable (0), Non-
confirmable (1), Acknowledgement (2), or Reset (3).
Token Length (TKL): 4-bit unsigned integer. Indicates the length of the variable-length
Token field (0-8 bytes). Lengths 9-15 are reserved, MUST NOT be sent, and MUST be
processed as a message format error.
Code: 8-bit unsigned integer, split into a 3-bit class (most significant bits) and a 5-bit detail
(least significant bits), documented as "c.dd" where "c" is a digit from 0 to 7 for the 3-bit
subfield and "dd" are two digits from 00 to 31 for the 5-bit subfield. The class can indicate a
request (0), a success response (2), a client error response (4), or a server error response (5).
(All other class values are reserved.) As a special case, Code 0.00 indicates an Empty
message.
Message ID: 16-bit unsigned integer in network byte order. Used to detect message
duplication and to match messages of type Acknowledgement/Reset to messages of type
Confirmable/Non confirmable.

16. 5. MQTT_SN
The purpose of this document is to specify MQTT-SN, a pub/sub protocol for
wireless sensor networks. MQTT-SN can be considered as a version of MQTT which is
adapted to the peculiarities of a wireless communication environment. Wireless radio links
have in general a higher failure rates than wired ones due to their susceptibility to fading and
interference disturbances. They have also a lower transmission rate.
For example, WSNs based on the IEEE 802.15.4 standard provide a maximum bandwidth of
250 kbit/s in the 2.4 GHz band. Moreover, to be resistant against transmission errors, their
packets have a very short length. In the case of IEEE 802.15.4, the packet length at the
physical layer is limited to 128 bytes. Half of these 128 bytes could be taken away by the
overhead information required by supporting functions such as MAC layer, networking,
security, etc.
MQTT-SN is also optimized for implementation on low-cost, battery-operated devices with
limited processing and storage resources.
MQTT-SN was originally developed for running on top of the ZigBeeR 1 APS layer.
ZigBeeR 1 is an open industrial consortium with the aim of defining an open and global
communication standard for WSNs. To be global ZigBeeR 1 has selected the IEEE standard
802.15.4 as the protocol for the PHY and MAC layers, and adds on top on this standard the
required network, security and application layers, thus providing interoperability between
products of different vendors.
MQTT-SN is designed in such a way that it is agnostic of the underlying networking
services. Any network which provides a bi-directional data transfer service between any node
and a particular one (a gateway) should be able to support MQTT-SN. For example a simple
datagram service which allows a source endpoint to send a data message to a specific
destination endpoint should be sufficient. A broadcast data transfer service is only required if
the gateway discovery procedure is employed. To reduce the broadcast traffic created by the
discovery procedure, it is desirable that MQTT-SN could indicate the required broadcast
radius to the underlying layer.
5.1 MQTT-SN Architecture
The architecture of MQTT-SN is shown in Fig. There are three kinds of MQTT-SN
components, MQTT-SN clients, MQTT-SN gateways (GW), and MQTT-SN forwarders.
MQTT-SN clients connect themselves to a MQTT server via a MQTT-SN GW using the
MQTT-SN protocol. A MQTT-SN GW may or may not be integrated with a MQTT server.
In case of a stand-alone GW the MQTT protocol is used between the MQTT server and the
MQTT-SN GW. Its main function is the translation between MQTT and MQTT-SN. MQTT-
SN clients can also access a GW via a forwarder in case the GW is not directly attached to
their network. The forwarder simply encapsulates the MQTT-SN frames it receives on the

17. wireless side and forwards them unchanged to the GW; in the opposite direction, it de
capsulate the frames it receives from the gateway and sends them to the clients, unchanged
too. Depending on how a GW performs the protocol translation between MQTT and MQTT-
SN, we can differentiate between two types of GWs, namely transparent and aggregating
GWs
fig 5.1 MQTT-SN Architecture
5.2Transparent Gateway
For each connected MQTT-SN client a transparent GW will setup and maintain a
MQTT connection to the MQTT server. This MQTT connection is reserved exclusively for
the end-to-end and almost transparent message exchange between the client and the server.
There will be as many MQTT connections between the GW and the server as MQTT-SN
clients connected to the GW. The transparent GW will perform a “syntax” translation
between the two protocols. Since all message exchanges are end-to-end between the MQTT-
SN client and the MQTT server, all functions and features that are implemented by the server
can be offered to the client. Although the implementation of the transparent GW is simpler
when compared to the one of an aggregating GW, it requires the MQTT server to support a
separate connection for each active client. Some MQTT server implementations might
impose a limitation on the number of concurrent connections that they support.

18. fig 5.2 Transparent and Aggregating Gate way
5.3 Aggregating Gateway
Instead of having a MQTT connection for each connected client, an aggregating GW
will have only one MQTT connection to the server. All message exchanges between a
MQTT-SN client and an aggregating GW end at the GW. The GW then decides which
information will be given further to the server. Although its implementation is more complex
than the one of a transparent GW, an aggregating GW may be helpful in case of WSNs with
very large number of SAs because it reduces the number of MQTT connections that the
server has to support concurrently.
5.4 Message Formats
General Message Format
Table 5.1 General Message Format
The general format of a MQTT-SN message is shown in Table 1. A MQTT-SN
message consists of two parts: a 2- or 4-octet long header and an optional variable part.
While the header is always present and contains the same fields, the presence and content of
the variable part depend on the type of the considered message
Message Header
The format of the message header is illustrated in Table 5.2

19. 5.5 Length
The Length field is either 1- or 3-octet long and specifies the total number of octets
contained in the message (including the Length field itself). If the first octet of the Length
field is coded “0x01” then the Length field is 3-octet long; in this case, the two following
octets specify the total number of octets of the message (most-significant octet first).
Otherwise, the Length field is only 1-octet long and specifies itself the total number of octets
contained in the message. The 3-octet format allows the encoding of message lengths up to
65535 octets. Messages with lengths smaller than 256 octets may use the shorter 1-octet
format. Note that because MQTT-SN does not support message fragmentation and
reassembly, the maximum message length that could be used in a network is governed by the
maximum packet size that is supported by that network, and not by the maximum length that
could be encoded by MQTT-SN.
6. Experimental Setup
Our experimental setup comprised a client and three servers. For the servers, we have
set up one local and two Amazon Web Services EC2 micro instances in Oregon and Tokyo.
All the servers run Ubuntu 14.04.2 LTS, JVM build 1.8.0. on the both local server3 and two
remote servers4. The client is a Raspberry Pi 2 model B5 running Debian GNU/Linux 7.8
(wheezy) and JVM build 1.8.0, connected via a wireless LAN. To measure energy
consumption, we have used Monsoon Power Monitor, a hardware based power profiling tool.
Table 6.1
Then, we selected widely used third-party IoT protocol implementations. Table
summarizes the libraries and their versions we used in the benchmarks. In particular, we have
used (1) java.net package for TCP, (2) javax.websocket package for Websocket, (3)
Californium6 for CoAP, and Paho7 for MQTT/MQTT-SN, respectively.

20. All the libraries are provided by the IoT working group of Eclipse Foundation. We have
experimented without any modification on library except MQTT-SN. However, because
none of third party MQTT-SN implementations does not support transferring large messages,
we modified the Paho library (i.e., version 1.3) to publish a large message up to 65,535 bytes.
Algorithm shows how experimented with each protocol to assess performance, resource
usages and energy efficiency on the client side. We do not measure the energy consumed by
the server. First, to warm the JVM, the benchmark application sends small dummy data three
times and then sends a randomly generated message to a remote server using different packet
lengths ranging from 128 bytes to 1920 bytes. To measure the CPU and Java heap usage,
used jvmTop [8] and the proc[pid]stat file, respectively.
6.1 Algorithm 1 Benchmark procedure for each protocol
1: for all target size in [128, 256, 512, ... 1920] do
2: Connect to Server
3: for i = 0 to 3 do
4: send 5Bytes data
5: end for
6: start power monitoring
7: start cpu ← copy proc/pid/stat
8: message ← 50Kb random string
9: for i = 0 to 20 do
10: start time ← current time
11: repeat
12: packet ← read target size from message
13: send packet
14: until message is empty
15: end time ← current time
16: trans time ← start time − end time
17: end for
18: Disconnect to Server
19: end cpu ← copy proc/pid/stat
20: stop power monitoring
21: end for
We have experimented with three local and remote servers that have the following respective
network characteristics. As described in Table 6.2,
Table 6.2

21. 6.2 Experimental Results
1) Performance: compares the performance of five protocols with respect to the
average transmission time when sending a 50kB message to three servers using different
packet lengths. As expected, the plain TCP implementation consistently showed the best
performance across all benchmarks, but surprisingly the WebSocket Protocol also showed
the similar results. MQTT-SN showed the poorest results in the local and Oregon cases while
the performance of MQTT improves as the packet size increases. Because MQTT-SN uses
UDP as a transport protocol while MQTT uses TCP, MQTT-SN is particularly vulnerable to
limited network conditions than MQTT. Even though CoAP is a UDPbased protocol, it
outperforms MQTT and MQTT-SN when its packet size is less than 1024 bytes. When the
packet size of CoAP becomes larger than 1024 bytes, CoAP internally fragments the large
packet into small blocks, thereby raising up the total transmission time. Moreover, due to the
lack of retransmission mechanisms in UDP, MQTT-SN and CoAP easily become inefficient
under the limited network conditions as depicted in Figure . Thus, when the packet size is
relatively large, MQTT should be favored over CoAP.
2) Energy Efficiency: In this benchmark, we assess the energy efficiency of each protocol. To
that end, we first measured the total amount of energy consumed by each protocol during the
entire benchmark. Limited network conditions such as latency, jitter, packet loss rate are
usually known to increase the energy cost of network processing . However, TCP and
WebSocket protocols are not affected by servers’ physical locations that have different
delay/bandwidth characteristics as described in Table 6.2 . In contrast, the energy efficiency
of CoAP, MQTT, and MQTT-SN is considerably vulnerable to network conditions due to the
underlying transport protocols (TCP or UDP), frequent packet fragmentation (CoAP),
straightforward retransmission mechanisms (CoAP, MQTT, and MQTT-SN), poor
implementation (MQTT-SN), etc.
Table 6.3
Then, we broke down the total energy consumption into the amount of energy consumed
when using different packet sizes. Figure shows the amount of energy consumed by each
protocol when varying the packet size.

22. fig 6.1 Performance comparison(a. local, b. organ,c. tokyo)
fig 6.2 Energy consumption comparison (a. local, b. organ,c. tokyo)
Similar to the performance characteristics, MQTT-SN showed the poorest results
while TCP and WebSocket showed the best results. Similarly, CoAP’s energy consumption
increases when the packet size becomes larger than 1024 bytes due to the fragmentation.
When the packet size of MQTT is larger than 1024 bytes in Oregon and Tokyo cases, it
consumes less energy than CoAP. Thus, when the packet size is relatively large, MQTT
should be favored over CoAP.
3) Resource Usage: CPU and Java Heap: Next, assess resource usages in terms of CPU and
memory. As IoT applications run on resource-constraint small devices, the resource usage of
network protocols should be considered. Figure shows the CPU time and and Java heap
usage during the test. The CPU time is computed as follows: utime + ptime of
proc[pid]stat. Similar to the performance and energy efficiency characteristics, the CPU
usage of MQTT-SN significantly increases especially when the client is connected to the
local and Oregon server and the packet size increases. To assess memory usage, we have
measured the Java heap size of each protocol. As depicted in Figure while the Java heap
usage of TCP and WebSocket is consistent regardless the physical location of servers, CoAP,
MQTT, and MQTT-SN consume more memory spaces. In particular, CoAP requires more
memory space than other protocols when the client is connected to Oregon and Tokyo
servers. However, we could not observe the similar patterns shown in performance, energy
consumption, and CPU time experiments due to fragmentation. This experimental results

23. show that CoAP’s retransmission mechanism mainly affected the memory usage rather than
the CPU usage.
C. Results Analysis
In this section some of the implications of the performance, energy efficiency and resource
usage measurements presented above. First, regardless of the distance between a client and a
server, our experiments show that MQTT and CoAP protocols are largely affected by the
packet size. In particular, CoAP and MQTT start to fragment a packet from 1 kB and 1.5 kB
respectively. In other words, if an application utilizes the MQTT protocol, the packet size
should be up to 1.5 kB for the performance and energy efficiency. If a programmer wants to
use REST-like APIs, the packet size of CoAP should be less than 1 kB to avoid
performance/energy overheads caused by the error recovery. In particular, in order to recover
errors due to packet losses or delays, CoAP employs a straightforward retransmission
mechanism using exponential back off time on top of UDP while MQTT relies on the TCP’s
error recovery mechanism. Furthermore, due to poor implementation, MQTT-SN is not ready
for real-world mobile software development. Finally, because TCP and WebSockets often
outperform IoT protocols.
7.Threats to Validity
The experimental results are subject to both internal and external validity threats. The
internal validity is threatened by the way in which we chose to use one library per one
protocol to compare protocols. Experiment results, especially resource and energy
consumption affected by their implementation. Therefore it has possibility that other library
and framework implement the protocol with more efficient or inefficient way. The way we
used these protocols in the benchmarks may not be fully optimal, in terms of the
configuration options specified. We use default configuration proved by official distribution
or documents. It is likely that a programmer deeply experienced in any of the measured
library may implement the same functionality exhibiting the performance and
resource/energy consumption patterns differing from our observations. The external validity
is threatened by our measurement infrastructure. Rather than use the restricted environment
by manual configuration, we choose cloud server physically locates a different region.
However, in the most our test cases, Oregon and Tokyo have a similar pattern. So we can
expect other remote server will have similar results with our experiment.

24. 8.RELATED WORK
To the best of our knowledge, this work is the first attempt to assess the performance,
energy consumption, and resource usage characteristics of IoT protocols. However, several
prior efforts have informed and inspired this work. Two IoT protocols—CoAP and MQTT—
have been assessed in terms of energy consumption, bandwidth utilization and reliability .
According to the result, CoAP is the most efficient in terms of energy consumption and
bandwidth usage while MQTT provides high reliability. compare these two IoT protocols
with multiple application scenarios and then suggest that MQTT is more appropriate for
applications that require advanced functions such as message persistence, secure multicast
and reliability. In measure performance of these protocols with different packet lost rates and
delay/bandwidth characteristics. According to the study, MQTT offers better throughput than
CoAP in congested networks. characterized the transmission behaviors of IoT protocols—
MQTT, CoAP and OPC UA (Open Platform Communication United Architecture)—in the
emulated networks including GSM (2G), UMTS (3G) and LTE (4G). Finally, MQTT and
CoAP have been assessed using a middleware system that can accommodate different
protocols . In these studies, IoT protocols have been assessed in terms of performance,
energy consumption or both while our study systematically compare five different protocols
in terms of performance, energy consumption, and resource (i.e., CPU and memory) usages.
Finally, in our prior work, we assessed different middleware mechanisms in terms of
performance, energy consumption, reliability, and programming effort. In particular, after
discovering that the network conditions can significantly affect how much energy is spend in
different middleware mechanisms, we created guidelines for mobile application programmers
to choose an appropriate middleware mechanism in a fashion that consumes the least amount
of energy or takes the shortest time for a given mobile network.
9. CONCLUSION AND FUTURE WORK
The IoT application programmers are faced with the challenges of choosing an
appropriate communication protocol for their resource-constrained applications. To assist the
programmers in their decision process, in this paper, we compared the performance, energy
efficiency, and resource usages of five different network protocols. As a future work, we plan
to conduct more systematic measurements of other IoT protocols with a wider range of user
scenarios including reliability, security, expressiveness (e.g., lines of code, complexity), etc.
We also plan to create systematic guidelines to help IoT application programmers make
informed decisions when choosing IoT protocols for their resource-constrained applications.

25. 10.REFERENCES
[1] Gartner, Inc., “Gartner Says the Internet of Things Installed Base Will Grow to 26 Billion
Units By 2020,” Dec. 2013.
[2] ABB Research, “30 Billion Devices Will Wirelessly Connect to the Internet of
Everything in 2020,” May 2013.
[3] G. D. Abowd, A. K. Dey, P. J. Brown, N. Davies, M. Smith, and P. Steggles, “Towards a
better understanding of context and context-awareness,” in Handheld and ubiquitous
computing,
1999.
[4] Z. Shelby, K. Hartke, and C. Bormann, “The constrained application protocol (CoAP),”
2014.
[5] OASIS, MQTT Version 3.1.1, Std., 2014.
[6] A. Stanford-Clark and H. L. Truong, “Mqtt for sensor networks (MQTT-SN) protocol
specification version 1.2,” 2013.
[7] I. Fette and A. Melnikov, “The Websocket Protocol,” 2011.
[8] patric-r/jvmtop. [Online]. Available: https://github.com/patric-r/ jvmtop
[9] Y.-W. Kwon and E. Tilevich, “The impact of distributed programming abstractions on
application energy consumption,” Information and Software Technology, 2013.
[10] A. Bhattacharyya and S. Bandyopadhyay, “Lightweight internet protocols for web
enablement of sensors using constrained gateway devices,” in Proceedings of the 2013
International Conference on Computing, Networking and Communications
(ICNC), 2013.
[11] N. De Caro, W. Colitti, K. Steenhaut, G. Mangino, and G. Reali,“Comparison of two
lightweight protocols for smartphonebased sensing,” in 2013 IEEE 20th Symposium on
Communications and Vehicular Technology in the Benelux (SCVT), 2013.
[12] M. Collina, M. Bartolucci, A. Vanelli-Coralli, and G. Corazza, “Internet of things
application layer protocol analysis over error and delay prone links,” in 2014 7th Advanced
Satellite Multimedia Systems Conference and the 13th Signal Processing for Space
Communications Workshop (ASMS/SPSC), 2014.
[13] L. Durkop, B. Czybik, and J. Jasperneite, “Performance evaluation of m2m protocols
over cellular networks in a lab environment,” in 2015 18th International Conference on
Intelligence
in Next Generation Networks (ICIN), 2015.
[14] D. Thangavel, X. Ma, A. Valera, H.-X. Tan, and C.-Y. Tan, “Performance evaluation of
mqtt and coap via a common middleware,” in 2014 IEEE Ninth International Conference on
Intelligent Sensors, Sensor Networks and Information Processing (ISSNIP),, 2014