IoT Communication Protocols

Internet of Things: Foundations and Applications [./]
Spring 2015 — INFO 290 (CCN 41607)

Erik Wilde, Siemens Web of Things Research Group
2015-04-03

[http://creativecommons.org/licenses/by/3.0/]

This work is licensed under a CC
Attribution 3.0 Unported License [http://creativecommons.org/licenses/by/3.0/]

Contents Erik Wilde: IoT Communication Protocols

Contents

2Abstract
3So/Too Many Protocols
4People And Hammers
5Creating the Silver Unicorn Hammer
1 Constrained Application Protocol (CoAP)
- 7CoAP as tiny HTTP++
- 8Constrained RESTful Environments (CoRE) Link Format
- 9Concise Binary Object Representation (CBOR)
2 Extensible Messaging Protocol (XMPP)
- 11XMPP History
- 12XMPP Messaging
- 13XMPP Messaging Example
- 14Presence Information
- 15XMPP Roster Example
3 WebSocket
- 17Non-HTTP Internet Connectivity
- 18HTTP to WebSocket Upgrade
- 19WebSocket Protocol
4 Advanced Message Queueing Protocol (AMQP)
- 21Asynchronous Enterprise Messaging
5 Message Queue Telemetry Transport (MQTT)
- 23An IoT Funnel Protocol
6 Web Real Time Communications (WebRTC)
- 25More P2P Than IoT
7 PubSubHubbub (PuSH)
- 27Push as a Pattern
- 28PuSH Subscription Flow
8 Conclusions
- 30Architecture is Hard

Erik Wilde: IoT Communication Protocols

(2) Abstract

In this lecture we are looking at both lower layer (CoAP) and specific communication protocols (XMPP, WebSocket, AMQP, MQTT, WebRTC, PuSH), as examples of how specific requirements in application areas have resulted in a variety of protocols. The main challenge in this space is to not compare protocols feature-by-feature, but to understand what they do and do not cover, and what they have been designed for.

Erik Wilde: IoT Communication Protocols

(3) So/Too Many Protocols

Protocols/standards necessarily are a tradeoff
- Dedicated solutions can be more specialized/optimized
- Generalized solutions have advantages of reuse/interoperability
Even The Internet was not the only solution initially
- Open Systems Interconnection (OSI) [Internet and Web Layering; OSI Layers (1)] was developed as an alternative
- TCP/IP won and today is the only connectivity layer in most scenarios
As new scenarios emerge and become mainstream, the landscape evolves
- Initially, there are a few first movers
- After that, many different solutions are developed and used
- Eventually, very few proven solutions become (de-facto) standards

Erik Wilde: IoT Communication Protocols

(4) People And Hammers

If you've never seen a screw it looks a lot like a nail.

Erik Wilde: IoT Communication Protocols

(5) Creating the Silver Unicorn Hammer

The nice thing about standards is that there are so many to choose from.

Constrained Application Protocol (CoAP)

Outline (Constrained Application Protocol (CoAP))

Constrained Application Protocol (CoAP) [3]
Extensible Messaging Protocol (XMPP) [5]
WebSocket [3]
Advanced Message Queueing Protocol (AMQP) [1]
Message Queue Telemetry Transport (MQTT) [1]
Web Real Time Communications (WebRTC) [1]
PubSubHubbub (PuSH) [2]
Conclusions [1]

Constrained Application Protocol (CoAP) Erik Wilde: IoT Communication Protocols

(7) CoAP as tiny HTTP++

The target scenario is one of constrained nodes and networks
- Constrained nodes can be sensors with limited memory and processing power
- Constrained networks can be slow and unreliable and intermittent
CoAP is an extended subset of HTTP
- Not all HTTP methods are supported in CoAP
- CoAP supports non-HTTP features (push and multicast)
- CoAP is optimized for bandwidth and processing efficiency
CoAP is designed for datagram transport protocols (UDP instead of TCP)
- Requests and responses are matched through message tokens
- Multicast can be used to request responses from various resources
Standardized in IETF RFC 7252 [https://tools.ietf.org/html/rfc7252]

Constrained Application Protocol (CoAP) Erik Wilde: IoT Communication Protocols

(8) Constrained RESTful Environments (CoRE) Link Format

Intended as resource discovery representation for CoAP
CoAP servers publish CoRE as one way for discovering resources

CoRE supports filters when discovering resources

REQ: GET /sensors

RES: 2.05 Content
</sensors/temp>;rt="temperature-c";if="sensor",
</sensors/light>;rt="light-lux";if="sensor"

Standardized in IETF RFC 7049 [https://tools.ietf.org/html/rfc7049]

Constrained Application Protocol (CoAP) Erik Wilde: IoT Communication Protocols

(9) Concise Binary Object Representation (CBOR)

Intended as a compact data representation format for CoAP
- Structurally following the capabilities of JSON
- Adding type information which allows more efficient encoding
Main goal is processing efficiency, not representation compactness
- Smaller than JSON but not as small as complex compression
Standardized in IETF RFC 6690 [https://tools.ietf.org/html/rfc6690]

Extensible Messaging Protocol (XMPP)

Outline (Extensible Messaging Protocol (XMPP))

Constrained Application Protocol (CoAP) [3]
Extensible Messaging Protocol (XMPP) [5]
WebSocket [3]
Advanced Message Queueing Protocol (AMQP) [1]
Message Queue Telemetry Transport (MQTT) [1]
Web Real Time Communications (WebRTC) [1]
PubSubHubbub (PuSH) [2]
Conclusions [1]

Extensible Messaging Protocol (XMPP) Erik Wilde: IoT Communication Protocols

(11) XMPP History

Originally named Jabber and intended as an open chat protocol
- Most chat systems are using closed and proprietary protocols
- XMPP allows an open ecosystem of chat services and clients to evolve
Main development within IETF from 2002-2004
XML was en vogue back then so the protocol is XML-based
- The entire client/server session is one XML document (a stream [http://tools.ietf.org/html/rfc6120#section-4])
- Stream children are XMPP's protocol data units (a stanza [http://tools.ietf.org/html/rfc6120#section-8])
- XMPP restricts XML [http://tools.ietf.org/html/rfc6120#section-11] so that parsing is a bit simpler
XMPP is specified as a generic core and an IM protocol
- XMPP Core (IETF RFC 6120) [http://tools.ietf.org/html/rfc6120]
- XMPP Instant Messaging and Presence (IETF RFC 6121) [http://tools.ietf.org/html/rfc6121]
- XMPP Address Format (IETF RFC 6122) [http://tools.ietf.org/html/rfc6122]

Extensible Messaging Protocol (XMPP) Erik Wilde: IoT Communication Protocols

(12) XMPP Messaging

XMPP protocol data units are predefined XML elements
- Each of these elements occur as children of the XMPP stream
<message/> [https://tools.ietf.org/html/rfc6120#section-8.2.1] is a unidirectional push mechanism (like email)
- Used for sending individual IM messages
<presence/> [https://tools.ietf.org/html/rfc6120#section-8.2.2] broadcasts presence information to subscribers
- Used for broadcasting presence updates to authorized subscribers
<iq/> [https://tools.ietf.org/html/rfc6120#section-8.2.3] is used for bidirectional request/response interactions
- Used for requesting address book information (the roster) from a server

Extensible Messaging Protocol (XMPP) Erik Wilde: IoT Communication Protocols

(13) XMPP Messaging Example

C: <?xml version='1.0'?>
   <stream:stream to='example.com'
                  xmlns='jabber:client'
                  xmlns:stream='http://etherx.jabber.org/streams'
                  version='1.0'>
S: <?xml version='1.0'?>
   <stream:stream from='example.com'
                  id='someid'
                  xmlns='jabber:client'
                  xmlns:stream='http://etherx.jabber.org/streams'
                  version='1.0'>

...  encryption, authentication, and resource binding ...

C:   <message from='juliet@example.com'
              to='romeo@example.net'
              xml:lang='en'>
C:     <body>Art thou not Romeo, and a Montague?</body>
C:   </message>
S:   <message from='romeo@example.net'
              to='juliet@example.com'
              xml:lang='en'>
S:     <body>Neither, fair saint, if either thee dislike.</body>
S:   </message>
C: </stream:stream>
S: </stream:stream>

xmpp-session.txt

Extensible Messaging Protocol (XMPP) Erik Wilde: IoT Communication Protocols

(14) Presence Information

Presence information is a critical part of every IM experience
- It is what drives the UX to see who is online and who is offline
- Managing presence is tricky because of scalability issues and privacy
XMPP handles presence via a subscription model
- Users send requests for subscriptions which can be approved or denied
- If a user has been approved to see presence information they have a subscription
- Subscription information is managed in a user's roster
XMPP manages a user's contact information in the roster
- The roster is managed by the server that manages a user's account
- It's the IM address book of a user and thus must be access-controlled

Extensible Messaging Protocol (XMPP) Erik Wilde: IoT Communication Protocols

(15) XMPP Roster Example

C: <iq from='juliet@example.com/balcony'
       id='hu2bac18'
       type='get'>
     <query xmlns='jabber:iq:roster'/>
   </iq>


S: <iq id='hu2bac18'
       to='juliet@example.com/balcony'
       type='result'>
     <query xmlns='jabber:iq:roster' ver='ver11'>
       <item jid='romeo@example.net'
             name='Romeo'
             subscription='both'>
         <group>Friends</group>
       </item>
       <item jid='mercutio@example.com'
             name='Mercutio'
             subscription='from'/>
       <item jid='benvolio@example.net'
             name='Benvolio'
             subscription='both'/>
     </query>
   </iq>

xmpp-roster.txt

WebSocket

Outline (WebSocket)

Constrained Application Protocol (CoAP) [3]
Extensible Messaging Protocol (XMPP) [5]
WebSocket [3]
Advanced Message Queueing Protocol (AMQP) [1]
Message Queue Telemetry Transport (MQTT) [1]
Web Real Time Communications (WebRTC) [1]
PubSubHubbub (PuSH) [2]
Conclusions [1]

WebSocket Erik Wilde: IoT Communication Protocols

(17) Non-HTTP Internet Connectivity

XMLHttpRequest [https://www.w3.org/TR/XMLHttpRequest2/] kicked off Web 2.0 but is limited
- The first time web apps can access the network to request information
- Allows any content (not just XML), but is limited to HTTP
WebSocket was initially part of HTML5 but then was spun off
WebSocket is both an API and a Protocol
- W3C publishes the WebSocket API [http://www.w3.org/TR/websockets/]
- IETF publishes the WebSocket Protocol [https://tools.ietf.org/html/rfc6455]
The WebSocket API allows web apps to open and use WebSocket connections
- Intended for any communications beyond HTTP's request/response pattern
- The most popular pattern are long-lasting connections for live updates

WebSocket Erik Wilde: IoT Communication Protocols

(18) HTTP to WebSocket Upgrade

GET ws://echo.websocket.org/?encoding=text HTTP/1.1
Origin: http://websocket.org
Cookie: __utma=99as
Connection: Upgrade
Host: echo.websocket.org
Sec-WebSocket-Key: uRovscZjNol/umbTt5uKmw==
Upgrade: websocket
Sec-WebSocket-Version: 13

websocket-upgrade-request.txt

HTTP/1.1 101 WebSocket Protocol Handshake
Date: Fri, 10 Feb 2012 17:38:18 GMT
Connection: Upgrade
Server: Kaazing Gateway
Upgrade: WebSocket
Access-Control-Allow-Origin: http://websocket.org
Access-Control-Allow-Credentials: true
Sec-WebSocket-Accept: rLHCkw/SKsO9GAH/ZSFhBATDKrU=
Access-Control-Allow-Headers: content-type

websocket-upgrade-response.txt

WebSocket Erik Wilde: IoT Communication Protocols

(19) WebSocket Protocol

WebSocket sends data in frames
- Frames are created when WebSocket peers exchange data
- Frames can carry either binary data or text
- send(data) API automatically decides which frame type to use
Fragmentation allows frames to be of unknown size when started
- Frames can be followed by continuation frames when fragmented
- Fragments have no semantics and are simply a frame transfer mechanism
Control frames are used to communicate WebSocket state
- Close frames are used to tear down WebSocket connections
- Ping/Pong frames are used as a way to exchange heartbeat information

Advanced Message Queueing Protocol (AMQP)

Outline (Advanced Message Queueing Protocol (AMQP))

Constrained Application Protocol (CoAP) [3]
Extensible Messaging Protocol (XMPP) [5]
WebSocket [3]
Advanced Message Queueing Protocol (AMQP) [1]
Message Queue Telemetry Transport (MQTT) [1]
Web Real Time Communications (WebRTC) [1]
PubSubHubbub (PuSH) [2]
Conclusions [1]

Advanced Message Queueing Protocol (AMQP) Erik Wilde: IoT Communication Protocols

(21) Asynchronous Enterprise Messaging

Originating in the world of financial institutions
- Typical scenarios are stock trading and other high-volume applications
- Protocols need to be optimized for speed and efficiency
- The goal is to efficiently route message from producers to consumers
- An attempt to get out of lock-in of proprietary IBM protocols
The basic AMQP model has four entities
- Producers create messages and then publish them to exchanges
- Exchanges receive messages and then distribute them to queue(s) using bindings
- Queues store messages so that consumers can receive them
- Consumers fetch messages from queues or get them by subscription
AMQP is intended for large-scale but coordinated environments
- A good fit for settings where application development is centrally controlled
- A bad fit for an open and decentralized setting with management of exchanges/queues

Message Queue Telemetry Transport (MQTT)

Outline (Message Queue Telemetry Transport (MQTT))

Constrained Application Protocol (CoAP) [3]
Extensible Messaging Protocol (XMPP) [5]
WebSocket [3]
Advanced Message Queueing Protocol (AMQP) [1]
Message Queue Telemetry Transport (MQTT) [1]
Web Real Time Communications (WebRTC) [1]
PubSubHubbub (PuSH) [2]
Conclusions [1]

Message Queue Telemetry Transport (MQTT) Erik Wilde: IoT Communication Protocols

(23) An IoT Funnel Protocol

Initiated by IBM and similar in scope to AMQP [Advanced Message Queueing Protocol (AMQP) (1)]
- Instead of AMQP's exchanges/queues, MQTT uses the concept of a message broker
- Message brokers handle subscriptions and distribution to interested clients
MQTT specifically targets constrained environments
- Small code foot print in order to fit onto embedded devices
- Limited network bandwidth to work in constrained networks
Various Quality of Service (QoS) levels allow support for different networks
- At most once delivery sends once and does not retry
- At least once delivery resends until a confirmation has been received
- Exactly once delivery suppresses duplicates on the receiver side
Mostly, MQTT is used to funnel sensor readings into a collection point

Web Real Time Communications (WebRTC)

Outline (Web Real Time Communications (WebRTC))

Constrained Application Protocol (CoAP) [3]
Extensible Messaging Protocol (XMPP) [5]
WebSocket [3]
Advanced Message Queueing Protocol (AMQP) [1]
Message Queue Telemetry Transport (MQTT) [1]
Web Real Time Communications (WebRTC) [1]
PubSubHubbub (PuSH) [2]
Conclusions [1]

Web Real Time Communications (WebRTC) Erik Wilde: IoT Communication Protocols

(25) More P2P Than IoT

WebRTC's main application area is real-time audio/video between clients
- A client/client model different from WebSocket [WebSocket (1)]'s client/server model
- In order to initiate client/client connections some signaling often is necessary
It started as an API, but network APIs without protocols are not open
- W3C is developing the WebRTC API [http://www.w3.org/TR/webrtc/] (how to use WebRTC in JavaScript)
- IETF is developing WebRTC protocols [http://datatracker.ietf.org/wg/rtcweb/documents/] so that browsers can communicate
WebRTC usually needs three important APIs
- MediaStream [http://www.w3.org/TR/mediacapture-streams/] to get access to data streams (such as camera and microphone)
- RTCPeerConnection [http://www.w3.org/TR/webrtc/] for audio or video calling (including encryption and bandwidth management)
- RTCDataChannel [http://www.w3.org/TR/webrtc/] for peer-to-peer communication of generic data
- Some sort of signaling often is necessary for getting client information
May be applicable to some P2P IoT scenarios

PubSubHubbub (PuSH)

Outline (PubSubHubbub (PuSH))

Constrained Application Protocol (CoAP) [3]
Extensible Messaging Protocol (XMPP) [5]
WebSocket [3]
Advanced Message Queueing Protocol (AMQP) [1]
Message Queue Telemetry Transport (MQTT) [1]
Web Real Time Communications (WebRTC) [1]
PubSubHubbub (PuSH) [2]
Conclusions [1]

PubSubHubbub (PuSH) Erik Wilde: IoT Communication Protocols

(27) Push as a Pattern

PuSH's idea is to extend distribution protocols with push facilities
- Distribution protocols (such as feeds or Activity Streams [Representational State Transfer (REST) and Activity Streams; Activity Streams Basics (1)]) may be client-driven
- By adding intermediaries (hubs), PuSH allows publish/subscribe for clients
- PuSH is not concerned with how sources and hubs are interacting
Hubs manage new entries and push updates to subscribers
- PuSH is only concerned about how to find hubs and get updates from them
- PuSH does not define a complete subscription management mechanism
- PuSH does not define how hubs get updates from the source
PuSH was intended for Atom feeds but then was decoupled from them
- PuSH changed significantly between 0.3 [http://pubsubhubbub.googlecode.com/svn/trunk/pubsubhubbub-core-0.3.html] and 0.4 [https://superfeedr-misc.s3.amazonaws.com/pubsubhubbub-core-0.4.html]
- It would be conceivable to define a PuSH AS Binding

PubSubHubbub (PuSH) Erik Wilde: IoT Communication Protocols

(28) PuSH Subscription Flow

Client discovers hub link in a server's information feed
Client POSTs subscription request to hub with a callback URI
Hub sends a verification request to check subscription request authenticity
Hub adds URI to its internal list of subscribed clients
Server and hub cooperate (push or pull) to get new content to the hub
Updates to server feeds are POSTed to callback URIs
Subscriptions (mostly) time out and have to be refreshed periodically

Conclusions

Outline (Conclusions)

Constrained Application Protocol (CoAP) [3]
Extensible Messaging Protocol (XMPP) [5]
WebSocket [3]
Advanced Message Queueing Protocol (AMQP) [1]
Message Queue Telemetry Transport (MQTT) [1]
Web Real Time Communications (WebRTC) [1]
PubSubHubbub (PuSH) [2]
Conclusions [1]

Conclusions Erik Wilde: IoT Communication Protocols

(30) Architecture is Hard

The current IoT landscape is in a consolidation phase
Picking protocols is part technology, part strategy, part politics
Changing protocols is hard, so trying to pick well is important

2015-04-03 Internet of Things: Foundations and Applications [./]
Spring 2015 — INFO 290 (CCN 41607)