The Internet of Things movement opens new possibilities for services and business along with new technological challenges, such as power efficiency, operation in constrained environments, security, and privacy. With the expectation of a high amount of devices connected in this Future Internet, scalability is also assumed to be a challenge. To address these limitations, several protocols are being proposed. In this paper, two of them, MQTT and COAP, are presented and qualitatively compared, summarizing their main features and limitations, highlighting the best scenarios where each approach is more suitable.

1. XXXIII SIMPÓSIO BRASILEIRO DE
TELECOMUNICAÇÕES – SBrT2015
Edielson P. Frigieri, Daniel Mazzer e Luís F. C. G. Parreira
M2M Protocols for Constrained
Environments in the Context of IoT:
A Comparison of Approaches
1

2. Outline
1 2 3 4
2
Introduction to
the protocols:
MQTT e CoAP
Constrained
environment
definition
Protocols
comparison
Conclusion

3. Outline
1
Introduction to
the protocols:
MQTT e CoAP
2
Constrained
environment
definition
3
Protocols
comparison
4
Conclusion
3

4. IoT Trends
4
This technology shift is expected to be
greater than the one caused by the
advent of mobile phones...

5. IoT Trends
5
... but IoT scenarios present very
constrained environments with millions or
even billions of devices...

6. IoT Trends
6
… which are motivating the design of
new protocols, focused on constrained
environments which demand only a few
transfers of bytes per day and should run
on battery powered devices for years.

7. Introduction: MQTT
Designed in 1999 by IBM and Eurotech
Easy to
implement
Simple
Lightweight
7

8. Introduction: MQTT
Based on publish/subscribe message pattern
Broker
Topic 1
Topic 2
Publisher
Subscriber
Subscriber
Publisher
Subscriber
Publisher
8

9. Introduction: MQTT
Whose main features...
Transports any kind of
data (Payload agnostic)
Full decoupling in time, space and
synchronization between
publishers and subscribers
9

10. Introduction: MQTT
... As well
Little transport overhead
(2 bytes fixed header)
Uses TCP/IP as the base
for communication
10

11. Introduction: MQTT
A new standard version with focus on sensor networks,
developed for running in different networks than TCP/IP
11

12. Introduction: CoAP
Designed by Constrained RESTful Environments (CoRE)
Working Group of Internet Engineering Task (IETF)
CoAP
Adapted from
HTTP
Minimal
subset of
REST
Focus on
devices with
constrained
power
and
processing
capabilities
12

13. Introduction: CoAP
Based on request/response model
Client
Server
Server
Client
Server
Client
REQUEST
REQUEST
RESPONSE
REQUEST
REQUEST
RESPONSE
13

14. Introduction: CoAP
Whose main features...
Connection is not
established before
message exchanging
Resources can be
accessed by URIs
14
Asynchronous information
push (observe option)

15. Introduction: CoAP
... As well
Little transport overhead
(compact 4 bytes header)
Uses UDP as the base
for communication
Small subset of methods
(POST, GET, PUT, DELETE)
15

16. Outline
1 2 3 4
16
Introduction to
the protocols:
MQTT e CoAP
Constrained
environment
definition
Protocols
comparison
Conclusion

17. Constrained environments
17
What can be considered
a constrained environment?

18. Constrained environments
18

19. Constrained environments
19
For this work…

20. Constrained environments
S
S
S
S
Gateway
S
Constrained
devices
Constrained
network
Internet
xDSL, LAN,
GPRS, 3G, etc.
Cloud
Service
capability
20
Constrained environment
15kbps ~ 1Mbps
>50kbps

21. Constrained environments
21
where…

22. Constrained environments
Sensors are composed by 8-32 bits
microcontrollers with 16-190 MHz
clock rate, 8K-64M bytes and 64K-1M
bytes flash memory.
Sensors are powered by batteries and
exchange data over unreliable networks.
22

23. Outline
1 2 3 4
23
Introduction to
the protocols:
MQTT e CoAP
Constrained
environment
definition
Protocols
comparison
Conclusion

24. Comparing the protocols
24
Implementation (size cost)
Data transport (transmission cost)
Communication patterns
Reliability and QoS
Scalability
Security
Open source implementations

25. Implementation
25
For both protocols there are C
implementations that does not
require dynamic memory
allocation and occupies about
35KB of ROM
Very good for a
constrained scenario!!
Both protocols have so many different
implementations, and each one may have been
tailored to attend different kind of applications.
Lightweight!

26. Data transport
26
MQTT uses TCP/IP
MQTT x CoAP
CoAP uses UDP/IP
Connection-oriented protocol
Pros:
• Ensures message delivery
• Flow control
Cons:
• More protocol data exchanged
• Processing cost
• Hard to implement on some
network topologies
Connection-less protocol
Pros:
• Lightweight
• Easy to implement
Cons:
• Message delivery not ensured
• No message sequencing

27. Data transport
27
MQTT x CoAP
Both protocols carry binary payload (data).
For mesh battery operated devices, TCP connections demand that all
nodes that are a path between two devices must store the connection
session, usually this is more complex to implement and more energy is
consumed. Using UDP connections, a node device just send an upward
message to its best parent or neighbor.

28. Data transport
28
MQTT-SN
To address the high resources needed by the TCP and also to allow MQTT
to operate over non IP networks, the SN version of the protocol was
released.
The MQTT-SN version may be implemented even over serial (uart/spi/…)
interfaces, and also over wireless protocols.
As the SN implementation is very hardware and solution specific, there is
no guarantee compatibility between implementations and brokers.

29. Communication patterns
29
Telemetry:
Information flows from device to other systems
Device status report, sensor information
Inquiries:
Requests from devices
Information request, asking to initiate activities
Commands:
System to device/devices
Execute specific activities, get device response
Notification:
System to a device/devices
Set configuration, FW upgrade, information

30. Communication patterns: MQTT
30
Telemetry
Inquiries
Commands
Notification
Very suitable
Device send messages to broker
Device does not need to know every destination address
Not very suitable, but possible
Developers must implement request/response by hand
Request/Response may be implemented on different topics
Request/Response context must be implemented by hand
Suitable, but tricky
Easy to implement on device
Server must control message response by hand
Command response may be implemented on different topic
Very suitable
Broker may retain notifications for devices
Server send and forget, broker will deliver the message
Devices receives notifications when connected to the broker

31. Communication patterns: CoAP
31
Telemetry
Inquiries
Commands
Notification
Possible, but tricky
Device send messages directly to destination
Sender must know address of all possible receivers
Receivers must accept external connections (NAT, 3G problem)
Suitable
CoAP is natively a request/response protocol
Request/Response context is maintained by the protocol
Suitable, but tricky
Device must be able to accept external connections
Command response context is maintained by the protocol
Not very suitable
When device is not always on, server must actively retransmit
Device must be able to accept external connections

32. Reliability and QoS
32
Both protocols provides means to define
some level of QoS (Quality of Service).
Reliability is directly defined by the
selected QoS and network environment.
The designer must take in account the data
exchange cost, network reliability, network
latency, message importance and many
other factors to choose a proper QoS level.
If messages loss is not such a problem, a lower QoS level can be used
resulting in lower bandwidth and lower end-to-end delay, which
configure wired or wireless constrained networks.

33. Reliability and QoS
33
MQTT V3.1 supports 3 levels of Quality of Service (QoS) that represents the
message delivery confidence. As the QoS level increases, there are more
acknowledgement messages and better reliability on message delivery.
Publisher Broker
PUBLISH (QoS=0)
Publisher Broker
PUBLISH (QoS=1)
Erase
Store
PUBACK
Publisher Broker
PUBLISH (QoS=2)
PUBCOMP
PUBREL
PUBREC
QoS=0 QoS=1 QoS=2
Erase Erase
Store

34. Reliability and QoS
34
On CoAP protocol the CON and NON messages acts as QoS levels, where the CON
message represents the higher QoS level. A request sent using NON type has no
acknowledge message sent back by the receiver, which characterizes a low QoS
level. The higher is the QoS level, the greater is the exchange of packets.
CoAP
client
CoAP
server
CON [0xcda1]
ACK [0xcda1]
High QoS
GET /temperature
2.05 Content
CoAP
client
CoAP
server
High QoS
(Token 0x71)
(Token 0x71)
“21.5”
CON [0xcda2]
ACK [0xcda2]
GET /temperature
4.04 Not found
(Token 0x72)
(Token 0x72)
“Not found”
CoAP
client
CoAP
server
NON [0xcda3]
GET /temperature
2.05 Content
(Token 0x73)
(Token 0x73)
“20.2”
Low QoS

35. Security
35
MQTT:
- Provides plain-text username and
password connection security.
- May use TLS (Security Socket Layer), if
implemented
- May use encrypted payload, if
implemented
CoAP:
- May use DTLS protocol (Datagram Transport Layer Security), if implemented.

36. Open source implementations
36
Both protocols have open source implementations written in
C, C++, Java, Python, JavaScript, Go, Objective-C and many
others.
Important: The implementations vary in coverage of
protocols specifications and some of them have some kind of
limitation.
Besides this may looks like a problem, in some applications
running over very constrained resources, an application
specific implementation is needed.
http://coap.technology/http://mqtt.org/

37. Outline
1 2 3 4
37
Introduction to
the protocols:
MQTT e CoAP
Constrained
environment
definition
Protocols
comparison
Conclusion

38. Conclusions
The use of TCP as transport protocol
limits its usage in more constrained
environments.
The message flow control can be
configured according to the necessity
using the available QoS options, which
in turn increases data rate and delay.
Security is one of the main problems
for all approaches and must be
reviewed for future versions.
All proposed protocols can achieve
scalability, where the protocols based
on publish/subscribed model have
simpler implementation. 38

39. Conclusions
Many open source implementations
for both protocols can be found
covering most application needs.
MQTT presented better accordance to
the presented communication
patterns besides that has a lightweight
and simple implementation.
CoAP can be applied in the context of
each thing being a resource that can
be accessed through an URL. This
feature allows CoAP devices easily
adapt to the current web services
available.
39

40. END
edielson@inatel.br
daniel.mazzer@inatel.br

41. References
• M. Collina, G. Corazza, and A. Vanelli-coralli, “Introducing the QEST broker:
Scaling the IoT by bridging MQTT and REST,” in 23rd Annual IEEE International
Symposium on Personal, Indoor and Mobile Radio Communications Introducing,
2012, pp. 36–41.
• Message Queuing Telemetry Transport, version 3.1, protocol specification.”
Eurotech, pp. 1–42, 2010.
• P. T. Eugster, P. a. Felber, R. Guerraoui, and A.-M. Kermarrec, “The many faces of
publish/subscribe,” ACM Computing Surveys, vol. 35, no. 2, pp. 114–131, 2003.
• Z. Shelby, “RFC 7252: The Constrained Application Protocol (CoAP).” pp. 1–112,
2014.
• J. Sen, “A Survey on Wireless Sensor Network Security,” Comput. Networks, vol.
52, no. 12, p. 24, 2010.
• J. H. Kong, L.-M. Ang, and K. P. Seng, “A comprehensive survey of modern
symmetric cryptographic solutions for resource constrained environments,” J.
Netw. Comput. Appl., pp. 1–36, Oct. 2014.
• P. Patierno, “IoT protocols war ! Battles on the fields”, Better Embedded, 2014.