This is a technical presentation describing two protocols namely MQTT and CoAP for IoT communications. This explains the protocols in conjunction with OSI layers.
4. 19-Dec-16
4
Communication between things.
Information flows from
device to other systems for
conveying status changes
in the device
Telemetry
Information flows from other
systems to a device or a group for
conveying status changes in the
world
Notifications
Commands from other
systems to a device or a
group of devices to perform
specific activities
Commands
Requests from devices
looking to gather required
information or asking to
initiate activities
Inquiries
5. 19-Dec-16
5
What’s it to do with Protocols?
Imagine the use case where
your phone communicates
with your lights. If it takes
several seconds before your
lights turn on, that’s a failed
user experience
• But these devices neither have the machine equivalent of
our normal personal computer systems nor run Web
browsers.
• These interconnected devices are usually of short range
low power wireless devices with their own predefined set
of operations or purpose.
Light Weight
Real Time
Messaging
• In the Internet of Things, autonomous electronic devices
exchange information with each other and with other
computer systems over the Internet.
• Real-time communication technology is an absolute
requirement for the development of Internet of things
(IoT) applications.
Because of this, the protocols that are currently used on the
internet cannot be directly used in these devices.
7. 19-Dec-16
7
Conventional Web Application Layer
• This layer interacts with software applications that implement a communicating
component.
• Identifying communication partners, determining resource availability, and
synchronizing communication.
• The Hypertext Transfer Protocol (HTTP) is an application protocol for distributed,
collaborative, hypermedia information systems.
Other Back logs
• No “messaging middleware”
• REST architecture
• Resources access by URIs
Heavy weight
• ASCII, text based headers
• client more complex (ASCII parser)
• more bytes to pay on data transfer
Push on client
• server sent events
• Long Polling
• no Quality of Service
9. 19-Dec-16
9
Application Layer for IoT : MQTT
• MQTT(Message Queuing Telemetry Transport) is a machine-to-machine (M2M)/"Internet
of Things" connectivity protocol.
• It was designed as an extremely lightweight publish/subscribe messaging transport. It is
useful for connections with remote locations where a small code footprint is required
and/or network bandwidth is at a premium
• MQTT was found by IBM and in 2013 it was donated to OASIS (Organization for the
Advancement of Structured Information Standards )
• The publish-subscribe
model requires a message
broker. The broker is for
distributing messages to
interested clients based
on the topic of a message.
10. 19-Dec-16
10
MQTT Features
Lightweight
• smallest packet size 2 bytes
(header)
• reduced clients footprint
Simple
• TCP based : socket connection oriented
• Asynchronous : no wait for response
• Publish/Subscribe : decoupling producers
and consumers
• Payload agnostic : any data format (text,
binary, JSON, XML)
Security
• MQTT is over TCP … use SSL/TLS for
security
• username/password on connection
• encrypt payload
Reliable
• Three QoS levels
• avoid packet loss on client disconnection
11. 19-Dec-16
11
MQTT : QOS
QoS 0: At most once (fire and forget)
QoS is a major feature of MQTT, it makes communication in unreliable networks a lot
easier because the protocol handles retransmission and guarantees the delivery of the
message, regardless how unreliable the underlying transport is.
13. 19-Dec-16
13
MQTT : QOS
QoS 2: At least once
PUBREC – Publish
received
PUBREL – Publish
release
PUBCOMP – Publish
complete
14. 19-Dec-16
14
MQTT : More about QOS (downgrade)
• QoS flow between a publishing and subscribing client are two different things and their
QoS can be different too.
• Between the sender and the broker the QoS is defined by the sender. When the broker
sends out the message to all subscribers, the QoS of the subscriber is used.
• If client B has subscribed to the broker with QoS 1 and client A sends a QoS 2 message, it
will be received by client B with QoS 1.
• All messages sent with QoS 1 and 2 will also be queued for offline clients, until they are
available again. But queuing is only happening, if the client has a persistent session.
15. 19-Dec-16
15
MQTT : Connection Types
Persistent Session
• Should a client has limited resources and the broker should hold its subscription, so the
communication can be restored quickly after it got interrupted. The client should resume
all QoS 1 and 2 publish messages after a reconnect.
Clean session
•It doesn’t need any session information to be stored on the broker and publishing
messages with QoS 1 and 2 should not be retried. A client should explicitly not get
messages for the time it is offline.
16. 19-Dec-16
16
MQTT : Keep Alive
• MQTT runs over TCP. In TCP is vulnerable to half-open connection.
• In half open connection, functioning end is not notified about the failure of the other side
and is still trying to send messages and wait for acknowledgements.
• The keep alive functionality assures that the connection is still open and both broker and
client are connected to one another. Keep alive is not checked as long as messages are
exchanged frequently and the keep alive interval is not exceeded.
• The broker will disconnect a client, which doesn’t send PINGREQ or any other message in
one and a half times of the keep alive interval.
17. 19-Dec-16
17
MQTT : Last Will and Testament
The Last Will and Testament (LWT) feature is used in MQTT to notify other clients about an
ungracefully disconnected client
Each client can specify its last will message when connecting to a broker. If the client
disconnect abruptly, the broker sends the message to all subscribed clients on the topic,
which was specified in the last will message.
The stored LWT message will be discarded if a client disconnects gracefully by sending a
DISCONNECT message.
19. 19-Dec-16
19
Application Layer for IoT : CoAP
• The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use
with constrained nodes and constrained networks in the Internet of Things.
• It is particularly targeted for small, low-power sensors, switches, valves and similar
components that need to be controlled or supervised remotely, through standard Internet
networks
• CoAP provides a request/response interaction model between application endpoints,
supports built-in discovery of services and resources .
• Each message is transferred along with a unique token.
20. 19-Dec-16
20
CoAP: Difference from HTTP
• Said that it is request/response model it is greatly different from HTTP. CoAP use mappings
from strings to integers to keep the data packets small enough.
• Unlike HTTP, CoAP deals with message exchanges asynchronously over a datagram-
oriented transport such as UDP. Thus CoAP is designed to be used with UDP.
• Message delivery is assured by CoAP messages by an application-level QoS. All CoAP
messages be marked as either “confirmable” or “nonconformable,”
• While SSL/TLS encryption isn’t available over UDP, CoAP makes use of Datagram Transport
Layer Security (DTLS), which is analogous to the TCP version of TLS.
• One of the downsides of CoAP: It's a one-to-one protocol. Though extensions that make
group broadcasts possible are available, broadcast capabilities are not inherent to the
protocol.
23. 19-Dec-16
23
CoAP –CoRE: Resource Discovery
• The Constrained RESTful Environments (CoRE) realizes the Representational
State Transfer (REST) architecture [REST] in a suitable form for the most
constrained nodes
• Observation & Block Transfer
• The discovery of resources offered by a CoAP endpoint is extremely important in machine-
to-machine application
• Resource Discovery can be performed either unicast or multicast a GET to "/.well-
known/core" on the server, which returns a payload in the CoRE Link Format.
27. 19-Dec-16
27
Understanding the Transport: TCP & UDP
TCP and UDP are the two transport protocols for IoT applications .
TCP
• TCP is used for most of our human interactions with the Web (e-mail, Web browsing, and
so on).
• TCP provides the concept of a logical connection, acknowledgement of transmitted
packets, retransmission of lost packets, and flow control.
• But for an embedded system, TCP can be overkill.
UDP
• The User Datagram Protocol (UDP) uses a simple connectionless transmission model with a
minimum of protocol mechanism.
• It has no handshaking dialogues, and thus exposes the user's program to any unreliability
• UDP is better suited for real-time data applications. This is why UDP, even if it has long
been relegated to network services such as DNS and DHCP, is now finding a new home in
sensor acquisition and remote control.
28. 19-Dec-16
28
Understanding the Transport: TCP & UDP
TCP UDP
Acronym for Transmission Control Protocol User Datagram Protocol or Universal Datagram Protocol
Connection TCP is a connection-oriented protocol. UDP is a connectionless protocol.
Function
As a message makes its way across the internet from one
computer to another. This is connection based.
UDP is a protocol used in message transport or transfer.
This is not connection based.
Usage
TCP is suited for applications that require high reliability,
and transmission time is relatively less critical.
UDP is suitable for applications that need fast, efficient
transmission, such as games. UDP's stateless nature is also
useful for servers that answer small queries from huge
numbers of clients.
Header Size TCP header size is 20 bytes UDP Header size is 8 bytes.
Weight
TCP is heavy-weight. TCP requires three packets to set up
a socket connection, before any user data can be sent.
TCP handles reliability and congestion control.
UDP is lightweight. There is no ordering of messages, no
tracking connections, etc. It is a small transport layer
designed on top of IP.
Error Checking
TCP does error checking and error recovery. Erroneous
packets are retransmitted from the source to the
destination.
UDP does error checking but simply discards erroneous
packets. Error recovery is not attempted.
Reliability
There is absolute guarantee that the data transferred
remains intact and arrives in the same order in which it
was sent.
There is no guarantee that the messages or packets sent
would reach at all.
29. 19-Dec-16
29
Internet layer: 6LoWPAN (IP suite)
• 6LoWPAN is an acronym of IPv6 over Low power Wireless Personal Area Networks.
• The 6LoWPAN concept originated from the idea that "the Internet Protocol could and
should be applied even to the smallest devices" and that low-power devices with limited
processing capabilities should be able to participate in the Internet of Things.
Security
• IPv6 also supports more-secure name resolution. The Secure Neighbor Discovery (SEND)
protocol is capable of enabling cryptographic confirmation that a host is who it claims to
be at the time of the connection.
• With IPv4, it’s fairly easy for an attacker to redirect traffic between two legitimate hosts
and manipulate the conversation or at least observe it—but IPv6 makes this very
difficult.
Scalability
• Trillions upon trillions of new addresses are important for IoT devices. IPv6 has larger
address resolution
30. 19-Dec-16
30
Physical Layer :
Bluetooth physical layer
CAN bus (controller area network) physical layer
DSL
Ethernet physical layer
GSM
Mobile Industry Processor Interface physical layer
Modulated ultrasound
Optical Transport Network (OTN)
SPI
SMB
SONET/SDH
USB physical layer