2013 International Conference on Computing, Networking and Communications, Workshops Cyber Physical System

Lightweight Internet Protocols for Web Enablement of Sensors using Constrained

Gateway Devices

Soma Bandyopadhyay Abhijan Bhattacharyya

Innovation Lab Innovation Lab
Tata Consultancy Services Tata Consultancy Services
Kolkata, India Kolkata, India
[email protected] [email protected]

Abstract— Lightweight Internet protocols are increasingly interfaces sensors embedded in the smart phone such as
being used in ubiquitous environment in order to optimize the GPS, accelerometer, microphone, etc. with external Internet
resource usage of a constrained device like a smart mobile facing system. Another example is a mobile healthcare-
gateway. This paper presents a study on the various such gateway which aggregates the various sensor data such as
protocols to optimize the usage of energy, and network blood pressure, blood sugar, ECG, etc. from portable
resources, computation cost of a constrained gateway device. sensors. Sensor data is aggregated, filtered, pre-processed,
Comprehensive analysis and feature wise categorization of analyzed and then posted to the backend applications in the
existing dominant protocols, namely MQTT (message queue cloud. In resource constrained gateway energy consumption,
telemetry transport), CoAP (constrained application protocol)
CPU cycles, memory usage, networking resources and
are provided here to achieve improved understanding of the
existing issues and gaps in this domain. The present work
bandwidth usage must be used as efficiently as possible.
further identifies the best suited application areas for each In this paper, we study existing lightweight application
protocol based on the results corresponding to typical resource protocols like CoAP (Constrained Application Protocol) and
requirements and performance attributes. Finally our vision MQTT (Message Queue Telemetry Transport). They are
on the research scope is presented here mainly for optimization compared considering various features such as energy
of energy usage. consumption, bandwidth utilization, reliability, etc. Based on
that analysis, these protocols are mapped to the best suited
Keywords-constrained device; ubiquitous computing; application areas. As CoAP supports both request-response
protocol;lightweight and resource-observe (a variant of pub-sub), this paper
illustrates how the adaptive feature of CoAP for request-
I. INTRODUCTION response and publish-subscribe mode, can be leveraged with
a common interface using sequence diagram and sate
The Internet of Things ( IoT) consisting of ubiquitous machine. Further, existing issues and gaps, and future
smart devices and objects with embedded sensors requires research scopes are analyzed and discussed based on the
energy and bandwidth efficient interfacing of resource- above review.
constrained devices with other devices, backend applications,
servers and other cloud hosted systems. Interoperation with a
wide variety of sensors and smart devices, semantic
interoperability, collection and analysis of sensor data,
context detection, predictive analytics and generation of
control and actuation outputs are some of the important
aspects of IoT applications. IoT applications require access
to sensor data in real-time as per their needs. The gateway
device is one of the most important components required for
realization of the IoT. It connects the sensor / device domain
to backend application/web service domain. In this paper we
consider those gateways that are low cost battery powered
embedded systems and have limited processing power,
memory and storage. Fig. 1 depicts the generic system
overview.
The gateway dynamically aggregates the real time sensor
data and shares the sensor data with the destination
server/application over Internet and at the same time
manages and controls the various diverse sensing-
devices/sensors. An example of a resource constrained
gateway is the smart mobile phone based gateway that Figure 1. A generic architecture for connecting Sensor to the Web.

978-1-4673-5288-8/13/$31.00 ©2013 IEEE 334

 The remainder of this paper is organized as follows. First, many a times uses proprietary and non-standard mechanism
the state-of-the art in the area of lightweight Internet and that part of the chain is hidden from the developer. The
protocols is presented, followed by their feature-wise open part is the communication mechanism over the link
comparison based on the underlying transport protocol, between the Constrained G/W and the applications situated
multicast capability, reliability, etc. The next section in the Cloud. So, the sensor specific link-layer and network
discusses how CoAP, originally envisaged as HTTP-like layer protocols like 6LowPAN is not considered here. Also,
request-response protocol, can work in publish-subscribe application protocols like MQTT-S is not relevant as MQTT-
mode, followed by a discussion on the architecture to create S is designed mainly for communication between the sensors
an adaptive solution for both the request-response and and the G/W i.e. for the sensor domain.
publish-subscribe using common CoAP methods. Next, Therefore, the study boils down to the two dominant
experimental results are presented to compare the resource application layer protocols CoAP and MQTT. Ref. [9]
requirements of CoAP and MQTT in terms of bandwidth, describes the use of CoAP at the G/W with a proxy to
and energy. The final section concludes this article with convert CoAP message to HTTP and vice-versa in order to
future research scope, and analyzes the gaps of the existing interpret with the common language of the Web, HTTP. It
light weight Internet protocols. also compares HTTP and CoAP in terms of power
consumption.
II. RELATED WORK However, there is no survey found which puts CoAP and
There has been a lot of work in the WSN domain in order MQTT side by side and compares them feature wise and
to connect the sensor data to the Web to enable a ubiquitous finds the suitable areas of applications for each. The present
connectivity between the Web and the sensor. Standard work brings out the features of both the protocols and
protocols have been designed keeping the constrained nature performs analysis based on the experimental results obtained
of the devices associated with WSN. There are two faces of by simulating network conditions using publish subscribe
the problem. Firstly, the sensors themselves are constrained mode of both the protocols. The current article also discusses
in terms of resources and they are connected to the Web about the adaptive architecture of CoAP for two different
directly or through a gateway. So the connection between the architectures request-response and resource-observe.
sensor to the Web or the G/W is a concern. Here the G/W is
not a resource constrained one. The other aspect of the III. FEATURES OF THE PROTOCOLS
problem unfolds when the G/W itself is a constrained device This section describes the features of the dominant light
like a smart mobile phone or TAB, etc., where large numbers weight Internet protocols as discussed in the previous section
of sensor devices communicate through the smart mobile and furnishes a feature wise comparison chart.
phone/ constrained gateway. In order to accomplish low CoAP is a Web transfer protocol based on the REST
power RF communication many sensors have adapted the (Representational State Transfer) [10] architecture. It is very
ZigBee specification for low power local wireless similar to HTTP. However, in order to avoid the overhead in
networking. Use of IPv6 over Low Power Wireless Area TCP like connection oriented protocols, CoAP is originally
Networking has given rise to the 6LowPAN standard at the designed to be used on top of UDP with provisions for a
link and network layer [1]. 6LowPAN enables the wireless reduced set of reliability mechanism like TCP. The optional
connectivity between sensors using 802.15.4 and IPv6 reliability is supported by a logical messaging layer on top of
together in a simple well understood way. UDP. Logically, CoAP can be considered as a single
In order to support the constrained applications two protocol suit of two logical layers: request/response layer on
dominant application layer protocols have been proposed to the top and messaging layer at the bottom to interact with the
connect the sensors to the Web, MQTT from IBM [2] and UDP. It supports 4 message categories: confirmable, non-
Constrained Object Application Protocol (CoAP) [3] from confirmable, acknowledgement and reset message. The
IETF. CoAP is based on request-response model. Ref. [4] confirmable type messages are used for reliable
demonstrates how CoAP over UDP can be a better choice communication. The confirmable message is accompanied
over other options like HTTP over TCP or HTTP over UDP by an acknowledgement from the receiving node to provide
considering the power consumption, header overhead and the reliability.
basic reliability feature supported by CoAP at the application Unlike HTTP, CoAP supports asynchronous message
layer itself. The MQTT protocol from IBM uses hierarchical exchange. CoAP has a low header overhead and parsing
topic based [11] ‘publish-subscribe’ mechanism and complexity than HTTP. Although CoAP is originally
facilitates the constrained devices by enabling ‘PUSHing’ [5] designed for UDP, it can be used for TCP as well [3].
data from the cloud rather than polling by constrained device The basic CoAP proposal has been extended to support
for the data from the server. However, in terms of resource-observe mode (which is similar to publish-
communicating to the end sensors in the WSN i.e. in the subscribe) in order to support features like supporting real
sensor domain, IBM has come up with yet another protocol time updates from sensors as proposed in [16] and explained
MQTT for Sensors (MQTT-S) [6] which is designed in such in Section IV.
a way that the protocol is agnostic of the underlying MQTT, as mentioned earlier, is absolutely based on topic
networking services. based publish-subscribe architecture with a message-broker
As can be seen in many available car, medical solutions to bridge between the publishers and subscribers. It exploits
(ex. [7], [8]), the sensor domain to G/W communication the decoupling in space, time and flow as the core of its

335
working philosophy. It supports three QoS (quality of
service) levels for message delivery with enhanced reliability
and has a low header overhead [2]. MQTT is a connection
oriented protocol as the publisher or the subscriber both
needs persistent connection to the message broker. It relies
on the underlying TCP layer for connection features.
Fig. 2 presents the mapping of these protocols in the OSI
stack.
Table I provides the feature wise comparison of these
protocols along with the potential application areas for CoAP
and MQTT.
Since CoAP uses a HTTP like request-response Figure 2. Mapping of protocols into the OSI stack.
architecture and resembles HTTP in many ways CoAP can
be well used for HTTP like GET, PUT, POST, DELETE
request based applications. Thus it can be used as the In this mode of operation CoAP clients called ‘observers’
protocol behind browsing like applications on a constrained register their interests about a specific resource in the
server. Potential applications may well use a proxy to namespace of a known server. The observers are notified
convert CoAP requests to HTTP, the language the Web is whenever the subject undergoes a change. The observers
more conversant with traditionally, as exemplified in [9]. register with the subject using the GET request with a
MQTT, by virtue of its inherent publish-subscribe special ‘observe’ option activated. The subject puts the
architecture, is very useful for ‘PUSH’ like application so as observer in the list of observers if it is allowed and responds
to free the constrained devices from resource hungry to the observer with an immediate state of the resource.
operations like ‘polling’ to get the updated data [5]. After the initial response each subsequent notification is an
However, in case of constrained edge gateways this protocol additional CoAP response sent by the server in reply to the
can be used for ‘publishing’ real time aggregated sensor data GET request and includes a complete representation of the
to the web-server asynchronously and with reliability. Efforts new resource state. Fig. 3 depicts an example scenario with
have been made to integrate MQTT [12] with ‘Pachube’, a 3 notifications.
widely popular technology for monitoring sensors and The resource observing model can be easily extended to
devices using ‘polling’, such that ‘Pachube’ can take publish/subscribe data exchange with a publisher client,
advantage of the MQTT broker by configuring triggers and subscriber clients and a broker in between utilizing PUT and
can be implemented using HTTP POST. ‘observable’ GET request from two independent clients.
However, CoAP seems to have a wider acceptance for Fig. 4 depicts the handshake in this case.
constrained devices due to ease of integration with
6LowPAN, easy portability with HTTP, UDP based
operation with low connection overhead, support for several
features like sleeping nodes [3] (without requiring persistent
connection), support for both request-response and resource-
observe mode, etc. Also, apart from the IETF, CoAP is
backed up by ETSI [22] and is poised for wide industry
adaptation as evident from the participation list in the recent
ETSI plug test of CoAP [18].
IV. COAP AS A PUBLISH/SUBSCRIBE PROTOCOL
The request/response model does not work well for
clients which are interested in having a current
representation of a resource/ sensor over a period of time.
Conventional method like polling also proves inefficient in
terms of resource usage for constrained devices. Thus, in
scenarios where real-time updates from the constrained
clients are required, MQTT may seem as an acceptable
solution. However, realizing the need for such real-time
feature of a proposed protocol, IETF extends the CoAP core
protocol with a mechanism to push resource representations
from servers to interested clients, while still keeping the
properties of REST [16].
Figure 3. An example resource observing exchange (from [16]).

336
 TABLE I.

Transport Supported Payload Response Max re- Multicast Reliability Typical application
layer architecture & header timeout transmit support area
structure

Mainly Publish- 2 bytes Configurable. Configurable One-to-many With 3 QoS Topic based real-time messaging
TCP [2]. subscribe header. Timeout message levels kind of application using pub/sub
Payload value distribution is requiring persistent connection
MQTT

treated increases inherently with the server. Message broker

as binary across supported is responsible to weave the
large multiple through pub- sensors with the rest of the Web.
object. retries sub. Ex. [19].

Mainly REST 4 byte Default 4[3]. ‘Resource Simple stop- Applications with sensors
UDP, TCP based header 2 seconds 0 for observe’ mode and-wait (possibly with defined sleeping
can be request / +Type [3]. multicast can be used for retransmission cycle) requiring to run RESTful
used but response, Length Can be one-to-many reliability web-services to achieve direct
not usually Resource Value configured. messaging. with connectivity to the Web (or
[3]. observe (TLV). Dedicated exponential optionally to some G/W) with
(Publish- Supports multicast back-off HTTP like methods and URI
subscribe) payload support exists [21] using either or both
CoAP

encoding but with no request/response or observing

like retransmission. resource (variant of real-time
XML pub/sub) mode. Ideal for
applications requiring easy
integration with the HTTP based
Web. Suitable for applications
like smart energy, building
automation, etc. [3].
publish/subscribe depending on how a client has configured
the GET call to the server. Thus the same architecture can
be fitted into different use cases for either publish/subscribe
or request/response. However, the server in the given mode
of interaction should have the logic of resource-observe
built into it so that it understands the ‘observe’ option in the
GET request from the client.
Fig. 5 shows how, with a single method, one can support
such an adaptive architecture. Fig. 5(a) shows the functional
flow on the server side. It shows how a GET request can be
served both for resource observe and request-response mode
depending on the option in the GET method and the
accessibility of the client with the server.
Fig. 5 (b) shows the state diagram for the client willing to
observe a resource on the server. Every resource has a
‘Max_age’ defined for the notified value [16]. If the client
finds a notification from the server which has an age greater
than the defined ‘Max_age’ then it understands that the
server is no longer keeping the client in the list of observers
and the client falls back into idle mode. The client can make
another observe request with a fresh token. Again, if the
Figure 4. Mapping conventional publish/subscribe paradigm into
CoAP resource observe mode of operation. client has to initiate a RST message then also it falls back
into non-observing mode.

V. COAP FOR AN ADAPTIVE ARCHITECTURE VI. EXPERIMENTAL ANALYSIS AND RESULTS

The discussion in the above section brings out an Current section performs an analysis of resource
advantage of CoAP. The configuration of the GET request requirements for CoAP and MQTT protocols based on
determines whether a client-server pair would interact in experimental results.
request-response or in resource-observe mode. Thus, The experiments were conducted using Intel X86 systems
without making any changes in the infrastructure, the same with Ubuntu installation as the nodes. Smart phone with
system can act both as a request/response and

337
Android O/S is planned as our future research platform. implementation for CoAP and MQTT respectively. It is
Fig. 6(a) depicts the experimental set up. worth mentioning here that the ‘libcoap’ distribution
supports IPv6. However, the modems used in the
experiment support only IPv4. So, the ‘libcoap’ code was
changed to support IPv4. This brings parity with the
‘mosquitto’ implementation which used IPv4 at the network
layer.
Different sample sensor data of constant size were used
as payload for both the protocols. Performance of the
protocols were studied by changing the packet loss
condition for a given payload size.
Fig. 7 and 9 shows the comparison between MQTT and
CoAP based on the actual network data transferred for
transferring different size of sensor payload with 0% packet
loss with CoAP in request-response mode and resource-
observe mode respectively. Fig. 8 and 10 shows the
comparison for 20% packet loss using CoAP in request-
response and resource-observe mode respectively.
It is obvious from the graphs that MQTT consumes
higher bandwidth than CoAP for transferring same payload
under same network condition. The MQTT traffic was
captured while MQTT publisher publishes data to the
broker. Since MQTT runs on TCP, it has TCP connection
overhead for connection establishment and closing. The
publisher client establishes a connection with the broker
first, followed by a ‘PUBLISH’ from the publisher. In case
of QoS 0 the publisher expects no more application layer
feedback from the broker and the TCP connection closes
with normal transport layer exchange of ACKs. But, in case
of QoS 2 the publisher performs additional exchanges with
the broker to ensure ‘exactly once’ delivery. This causes
more traffic than QoS 0 case.
On the other hand, CoAP has no connection overhead as
UDP works in ‘fire and forget’ basis. To ensure reliable
transmission, the CoAP messages were CON (confirmable)
messages with an application layer ACK message. But since
no connection was established there is no question of
overhead to close the connection. It has been observed that
as packet loss increases, total number bytes transferred also
increases because of retransmission.
It is important to note that in case of MQTT for packet
loss scenarios like Fig 8. and Fig. 10, when the actual bytes
sent is increased, the total bytes of data transferred dropped
Figure 5. a) Server side flow showing how a GET request can be because of an early connection closure during TCP
served both as request response (the dotted lines) and resource-
observe mode. b) The state m/c for the client for an ‘observe GET’ connection establishment or publisher broker handshaking
request. phase.
The data overhead analysis exposes the fact that topic
definition is proving to be an extra overhead in case of
The connection between the nodes was routed through
MQTT as the topic string itself is part of the payload.
an intermediate router known as Wide Area Network However, efficient formation of topic string using wild
Emulator (WANEM) [17] in order to control the network cards [11] may reduce the topic overhead for MQTT. On the
attributes for the experiment. WANEM allows controlling other hand, URI for locating resources forms a significant
the physical network properties like bandwidth, packet loss,
part of the CoAP packet [3] and an optimized URI path is
etc. to simulate constrained network, as shown in Fig. 6(b).
needed for reducing overhead.
Wireshark [20] tool was used to analyze the network traffic.
In terms of energy both the protocols are efficient. Detail
We used ‘libcoap’ [12] and ‘mosquitto’ [13] as the energy consumption figures for MQTT are available in [15]

338
for Android implementation. Fig. 11 shows the average based on our experimental data, where CoAP becomes most
energy consumed by MQTT and CoAP with reliability energy efficient.

(a) (b)

Figure 6. (a) The experimental set up using a private network for performing CoAP and MQTTperformance comparison.
(b) Simulating the different network conditions.

Figure 7. Data bytes sent for different sensor data posting with 0% Figure 9. Data bytes sent for different sensor data posting with 0%
packet loss with CoAP in request-response packet loss with CoAP in resource-observe

Figure 8. Data bytes sent for different sensor data posting with 20% Figure 10. Data bytes sent for different sensor data posting with
packet loss with CoAP in request-response 20% packet loss with CoAP in resource-observe

339
 association with over all QoS in a more efficient way,
where UDP is considered as basic transport layer protocol.
The protocols possess the low overhead for header
parsing; however optimized encoding for payload
compression is a further challenge to be resolved.
Preservation of privacy while carrying the sensor data
including the context information is also another open area
to be addressed. Currently we are pursuing our research
activity on the above mentioned open issues.
REFERENCES

[1] IPv6 over Low-Power Wireless Personal Area Networks

(6LoWPANs):Overview, Assumptions, Problem Statement, and
Goals, RFC 4919, IETF.
[2] MQTT V3.1 Protocol Specification (
http://public.dhe.ibm.com/software/dw/webservices/ws-mqtt/mqtt-
v3r1.html ).
Figure 11. Average Power Consumption with CoAP in resource-observe. [3] Constrained Application Protocol (CoAP) draft-ietf-core-coap-12
(http://tools.ietf.org/html/draft-ietf-core-coap-12 ).
[4] K. Kuladinithi, O. Bergmann, T. Pötsch, M. Becker and C. Görg,
"Implementation of CoAP and its Application in Transport
VII. CONCLUSION Logistics," in In Proc. of ‘Extending the Internet to Low power and
Lossy Networks’ (IP+SN 2011), Chicago, USA, Apr. 11, 2011.
In this article a survey of lightweight Internet protocols
is presented considering the scenario in which protocols [5] http://dalelane.co.uk/blog/?p=938.
are employed by constrained gateway devices for sharing [6] MQTT For Sensor Networks (MQTT-S) Protocol Specification
Version 1.2 ( http://mqtt.org/MQTT-S_spec_v1.2.pdf ).
dynamic sensor data to the applications. They are
[7] http://www.mobile-devices.fr/our-products/c4evo/.
compared based on their different protocol specific
characteristics as well as usage of resources like [8] http://www.etcomm.cn/en/products_hc-001.html.
bandwidth, energy. This comparison is further supported [9] W. Colitti, K. Steenhaut, and N. De Caro, “Integrating Wireless
Sensor Networks with the Web,” in Extending the Internet to Low
by the results obtained and the analysis on the experiment powerand Lossy Networks (IP+SN 2011), 2011.
where sensor data is transferred with different size in [10] http://tools.ietf.org/pdf/draft-griffin-bliss-rest-00.pdf
increasing order to the same destination over the same
[11] http://www.ibm.com/developerworks/lotus/library/expeditor-mqtt/.
communication link. Link characteristics are simulated by
[12] http://www.ibm.com/developerworks/websphere/library/techarticle
varying network conditions. The study represents mapping s/1106_maynard/1106_maynard.html?ca=drs-.
of these protocols to the different application domain [13] http://libcoap.sourceforge.net.
based on the analysis of the characteristics of these [14] http://mosquitto.org/download/.
protocols. The analysis of the experimental results depicts
[15] http://stephendnicholas.com/archives/219.
that CoAP is most efficient in terms of energy
[16] Observing Resources in CoAP draft-ietf-core-observe-05.
consumption as well as bandwidth. Architecture has been
[17] http://wanem.sourceforge.net/
discussed for adapting CoAP into two different modes,
request-response as well as resource-observe. [18] Sebastian M ller, “Preliminary results of 1st CoAP Plugtest”.
http://www.intelligentcontainer.com/uploads/media/Preliminary_R
Constrained gateway may overcome the limitation in esults_1st_CoAP__Plugtest.pdf .
processing speed as per the current trend, but managing [19] http://mqtt.org/2011/08/mqtt-used-by-facebook-messenger
energy in an efficient way is still an open issue. There is a [20] http://www.wireshark.org/
scope for future research work to design the protocols
[21] http://tools.ietf.org/pdf/draft-castellani-core-http-mapping-05.pdf
including their message handling, state machine design,
[22] http://www.etsi.org/plugtests/coap/coap.htm
supporting both request-response and publish subscribe
mode and switching between them intelligently to handle
the above mentioned issue. The state machine of these
protocols should handle the retransmissions and its

340