m2m protocols for constrained environments in the context of iot: a comparison of approaches

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

2

Outline

1 2 3 4Introduction to the protocols: MQTT e CoAP

Constrained environment

definition

Protocols comparison

Conclusion

3

Outline

1Introduction to the protocols: MQTT e CoAP

2Constrained environment

definition

3Protocols

comparison

4Conclusion

4

IoT Trends

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

5

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

6

IoT Trends

… which are motivating the design ofnew 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: MQTTDesigned in 1999 by IBM and Eurotech

Easy to implement

Simple

Lightweight

8

Introduction: MQTTBased on publish/subscribe message pattern

BrokerTopic 1

Topic 2

Publisher

Subscriber

Subscriber

Publisher

Subscriber

Publisher

9

Introduction: MQTTWhose main features...

Transports any kind of data (Payload agnostic)

Full decoupling in time, space and synchronization between

publishers and subscribers

10

Introduction: MQTT... As well

Little transport overhead (2 bytes fixed header)

Uses TCP/IP as the base for communication

11

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

MQTT-SN

...

12

Introduction: CoAPDesigned 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

13

Introduction: CoAPBased on request/response model

Client

Server

Server

Client

Server

ClientREQUEST

REQUESTRESPONSE

REQUEST

REQUEST

RESPONSE

14

Introduction: CoAPWhose main features...

Connection is notestablished before

message exchanging

Resources can be accessed by URIs

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)

16

Outline



definition


Conclusion

17

Constrained environments

What can be considered a constrained environment?

18


energy constraints

unreliable networks

memory limitationslimit processing capability

higher latency incommunicationunattended network operation

19


For this work…

20


S

S

S

S

Gateway

S

Constraineddevices

Constrainednetwork

Internet

xDSL, LAN, GPRS, 3G, etc.

Cloud

Service capability


15kbps ~ 1Mbps

>50kbps

21


where…

22

Constrained environmentsSensors 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.

23

Outline



definition


Conclusion

24

Comparing the protocols

Implementation (size cost)

Data transport (transmission cost)

Communication patterns

Reliability and QoS

Scalability

Security

Open source implementations

25

Implementation

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

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 transportMQTT 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 transportMQTT-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

Telemetry: Information flows from device to other systemsDevice status report, sensor information

Inquiries:Requests from devicesInformation request, asking to initiate activities

Commands: System to device/devicesExecute specific activities, get device response

Notification:System to a device/devices Set configuration, FW upgrade, information

30

Communication patterns: MQTTTelemetry

Inquiries

Commands

Notification

Very suitableDevice send messages to brokerDevice does not need to know every destination address

Not very suitable, but possibleDevelopers must implement request/response by handRequest/Response may be implemented on different topicsRequest/Response context must be implemented by hand

Suitable, but trickyEasy to implement on deviceServer must control message response by handCommand response may be implemented on different topic

Very suitableBroker may retain notifications for devicesServer send and forget, broker will deliver the messageDevices receives notifications when connected to the broker

31

Communication patterns: CoAPTelemetry

Inquiries

Commands

Notification

Possible, but trickyDevice send messages directly to destinationSender must know address of all possible receiversReceivers must accept external connections (NAT, 3G problem)

SuitableCoAP is natively a request/response protocolRequest/Response context is maintained by the protocol

Suitable, but trickyDevice must be able to accept external connectionsCommand response context is maintained by the protocol

Not very suitableWhen device is not always on, server must actively retransmitDevice must be able to accept external connections

32

Reliability and QoS

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 QoSMQTT 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 QoSOn 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.

CoAPclient

CoAPserver

CON [0xcda1]

ACK [0xcda1]

High QoS

GET /temperature

2.05 Content

CoAPclient

CoAPserver

High QoS

(Token 0x71)

(Token 0x71)“21.5”

CON [0xcda2]

ACK [0xcda2]

GET /temperature

4.04 Not found

(Token 0x72)

(Token 0x72)“Not found”

CoAPclient

CoAPserver

NON [0xcda3]GET /temperature

2.05 Content

(Token 0x73)

(Token 0x73)“20.2”

Low QoS

35

Security

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

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



definition


Conclusion

38

ConclusionsThe 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.

39

ConclusionsMany 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.

END

[email protected]@inatel.br

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.