1.
Internet Of Things
Protocols Review
Marcin
Bielak
Software
Engineer
Open Source
contributor
. | ,
_---_ /
-_ .' `. _-
__ : .---. : __
: / :
-" `. | | .' "-
/ |`-'|
' ]"-_[ `
]"-_[
"*"
o
|
|
+~11001~+
|
+~010001~+
|
|
|
|
|
|
|
|
+~11001011~+~bieli

2.
Agenda
- Introduction
- IoT protocols and standards
- MQTT
- HTTP/REST
- MQTT vs. HTTP/REST
- DDS
- MQTT vs. DDS
- IoT architectures
- Implementations & cloud dev.
IoT
Protocols review

3.
Hello world
- Who am I ?
- Open Source contributor* & user
- Open Hardware fanatic
- Software Engineer & DevOps
- Golang / Python / Java
- GNU Linux
- Sci-fi fanIoT
Protocols review
*) https://github.com/allegro/akubra , https://github.com/bieli

4.
-
IoT
Protocols
review http://directoryimd.com/article/telematics-the-industrial-internet-of-things-iiot-and-industry-40.html
Welcome industry 4.0

5.
Everything is “connected”
IoT Protocols
review
https://www.slideshare.net/BryanBoyd/mqtt-austin-api

6.
IoT
Protocols review
http://postscapes.com/what-exactly-is-the-internet-of-things-infographic/
IoT
sensors

7.
General reasons - why IoT ?
- Connect both inanimate and living things
- Use sensors for data collection (data streams)
- Change what types of item communicate over
an IP Network
- Benefits for today:
- Faster knowledge/stats sharing with M2M
- Better quality in control and automation
- Cost Savings (Machine Learning, Analytics)
IoT
Protocols review

8.
IoT
Protocols
review
https://cloudtweaks.com/2016/03/internet-of-things-investors/

9.
Communication protocol...
- ..., a defined set of rules and regulations
that determine how data is transmitted in
telecommunications and computer
networking
- machines languages in ‘Machine to
Machine’ (M2M) world
IoT
Protocols review

10.
Protocols are everywhere
IoT
Protocols review
protocols

11.
Typical protocols
for internet and industrial field
● DNS
● FTP
● HTTP / HTTPS
● IRC
● NNTP
● POP3
● SMTP
● SSH
● Telnet
● IMAP
● modbus
● profibus
● M-Bus
● S-Bus
● Foundation
Fieldbus
● BACnet
● LonWorks
● CAN bus
IoT
Protocols review

12.
MQTT - IoT protocol
IoT
Protocols review

13.
MQTT - general information
- Message Queuing Telemetry Transport (ver. 3.1.1)
- publish – subscribe messaging pattern
- requires a message broker
- asynchronous messages model (events)
- works on top of the TCP/IP protocol (possible TLS)
- lightweight, efficient and simple implementation
- Open Sourced with standards (40+ client libraries)IoT
Protocols review
http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html

14.
MQTT - design concept
IoT
Protocols review
https://www.slideshare.net/PeterREgli/mq-telemetry-transport

15.
MQTT - core elements
IoT
Protocols review
https://www.slideshare.net/PeterREgli/mq-telemetry-transport

16.
MQTT - topic wildcards
IoT
Protocols review
https://www.slideshare.net/PeterREgli/mq-telemetry-transport

17.
MQTT - message format
IoT
Protocols review
https://www.slideshare.net/PeterREgli/mq-telemetry-transport
(up to 250 MB)

18.
MQTT - fixed header fields
IoT
Protocols review
https://www.slideshare.net/PeterREgli/mq-telemetry-transport

19.
MQTT - Quality of Service
Even though TCP/IP provides guaranteed data delivery, data loss can still
occur if a TCP connection breaks down and message in transmit are lost.
Therefore MQTT adds 3 quality of service levels on top of TCP.
IoT
Protocols review
https://www.slideshare.net/PeterREgli/mq-telemetry-transport

20.
QoS for reliable messaging
IoT
Protocols review
https://www.slideshare.net/BryanBoyd/mqtt-austin-api
MQTT
Broker

21.
MQTT QoS - examples
QoS level 0 (best effort)
- temperature sensor data is regularly published
- lost of an individual value is not critical for application
QoS level 1 (quaranteed to arrive, but duplicated are possible)
- door sensor senses the door state
- it’s important how door state change (close->open, open->close)
- states are published losslessly to subscribers
QoS level 2 (exactly once)
- application where duplicated events could lead to incorrect actions, e.g.
sounding an alarm as a reaction to an event recived by the message
IoT
Protocols review

22.
MQTT client comparision
http://www.eclipse.org/paho/downloads.php
IoT
IoT Protocols
review

23.
MQTT toolbox
https://www.slideshare.net/Hamdamboy/message-queuing-telemetry-transport-mqtt
IoT
Protocols review
mqtt-spy
- is probably one of the most advanced open source utilities for publishing
and monitoring activity on MQTT topics. It is aimed at two groups of users:
- innovators who need a tool for creating IoT prototypes or integration
projects
- power users who need an advanced utility for their work
environments
mosquitto
- an open source MQTT broker (from Eclipse project)
- implements the MQTT protocol versions 3.1 and 3.1.1.
- is lightweight and is suitable for use on all devices from low power
single board computers to full servers
paho - MQTT client library implementrations http://www.eclipse.org/paho/

24.
HTTP + RESTful
IoT
Protocols review

25.
HTTP + RESTful
- The Hypertext Transfer Protocol (HTTP) is an application protocol for distributed,
collaborative, and hypermedia information systems.[1]
HTTP is the foundation of
data communication for the World Wide Web.
-
- REpresentational State Transfer (REST), or RESTful, web services provide
interoperability between computer systems on the Internet.
-
- created by the internet community with global companies support
- supported by all vendors, companies, organizations (wide range)
- based on RFC (Request for Comments)
- client/server libs exists in all (popular) programming lang.
- stateful, cached, scalable, session, extensible and secureIoT
Protocols review

26.
HTTP - design concept
IoT
Protocols review

27.
HTTP - typical flow
IoT
Protocols review
1) Open a TCP connection. The TCP connection will be used to send a request, or several, and receive an answer.
2) Send an HTTP message in ASCII. HTTP messages (before HTTP/2) are human-readable.
GET / HTTP/1.1
Host: developer.mozilla.org
Accept-Language: en
3) Read the response sent by the server:
HTTP/1.1 200 OK
Date: Sat, 09 Oct 2010 14:28:02 GMT
Server: Apache
Last-Modified: Tue, 01 Dec 2009 20:18:22 GMT
ETag: "51142bc1-7449-479b075b2891b"
Accept-Ranges: bytes
Content-Length: 29769
Content-Type: text/html
<!DOCTYPE html... (here comes the 29769 bytes of the requested web page)
4) Close or reuse the connection for further requests.

28.
HTTP Messages
IoT
Protocols review
REQUEST RESPONSE

29.
Uniform Resource Identifier
scheme:[//[user[:password]@]host[:port]][/path][?query][#fragment]
IoT
Protocols review
hierarchical part
┌───────────────────┴─────────────────────┐
authority path
┌───────────────┴───────────────┐┌───┴────┐
abc://username:password@example.com:123/path/data?key=value#fragid1
└┬┘ └───────┬───────┘ └────┬────┘ └┬┘ └───┬───┘ └──┬──┘
scheme user information host port query fragment
urn:example:mammal:monotreme:echidna
└┬┘ └──────────────┬───────────────┘
scheme path
https://tools.ietf.org/html/rfc3986 , https://en.wikipedia.org/wiki/Uniform_Resource_Identifier

30.
HTTP - status codes
IoT
Protocols review
- 1xx: Information. The request was received by the server,
continue processing.
- 2xx: Successful. The request was received, understood,
accepted, and processed by the server.
- 3xx: Redirection. Additional action is required to complete the
request.
- 4xx: Client Error. There was a problem with the request
received by the server.
- 5xx: Server Error. The request was received, understood, and
accepted by the server, however, a server error occurred in
processing the request.
https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

31.
HTTP - request methods
IoT
Protocols review
- OPTIONS
- GET
- HEAD
- POST
- PUT
- DELETE
- TRACE
- CONNECT
- PATCH
https://tools.ietf.org/html/rfc1738 , https://tools.ietf.org/html/rfc3187

32.
HTTP - classifying methods
IoT
Protocols review
https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol

33.
HTTP - types of headers
fields
IoT
Protocols review
- Authentication
- Caching
- Client hints
- Conditionals
- Connection management
- Content negotiation
- Controls
- Cookies
- CORS
- Downloads
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers
- Proxies
- Redirects
- Request context
- Response context
- Security
- Transfer coding
- Server-sent events
- WebSockets
- …

34.
HTTP still evolves
IoT
Protocols review
http://slideplayer.com/slide/10858611/

35.
HTTP 1.1 vs. HTTP/2
IoT
Protocols review
no pipelining vs. pipelining (better performance)
optional secure vs. secure by design
https://imagekit.io/demo/http2-vs-http1

36.
REST API - definition
IoT
Protocols review
- REST is a simple way to organize interactions
between independent systems (based on HTTP
protocol).
- Optimal usage of HTTP with few architectural constraints:
- Client-server architecture
- Statelessness
- Cacheability
- Layered system
- Uniform interface
- Code on demand (optional)
https://tools.ietf.org/html/rfc1738 , https://tools.ietf.org/html/rfc3187

37.
REST API - design concept
IoT
Protocols review
https://tools.ietf.org/html/rfc1738 , https://tools.ietf.org/html/rfc3187

38.
REST API - design concept
IoT
Protocols review

39.
REST API - endpoints
IoT
Protocols review

40.
REST - data representations
IoT
Protocols review
JSON
{
"_type": "vm",
"name": "A virtual machine",
"memory": 1024,
"cpu": {
"cores": 4,
"speed": 3600
},
"boot": {
"devices": ["cdrom",
"harddisk"]
}
}
https://tools.ietf.org/html/rfc1738 , https://tools.ietf.org/html/rfc3187
YAML
!vm
name: A virtual machine
memory: 1024
cpu:
cores: 4
speed: 3600
boot:
devices:
- cdrom
- harddisk
XML
<vm
xmlns:xs="http://www.w3.org/2001/XMLSche
ma">
<name type="xs:string">My VM</name>
<memory type="xs:int">1024</memory>
<cpu>
<cores type="xs:int">4</cores>
<speed type="xs:int">3600</speed>
</cpu>
<boot>
<devices type="xs:list">
<device
type="xs:string">cdrom</device>
<device
type="xs:string">harddisk</device>
</devices>
</boot>
</vm>

41.
Relationship between URL
and HTTP methods
IoT
Protocols review
https://en.m.wikipedia.org/wiki/Representational_state_transfer

42.
REST IoT solutions (hubs)
IoT
Protocols review
- The REST APIs for IoT Hub offer programmatic access to
the device, messaging, and job services, as well as the
resource provider, in IoT Hub.
- Typical subjects for IoT hubs:
- Device Identities
- Device Twins
- Device Messaging
- Jobs
- Resource Provider
- Common error codes
https://docs.microsoft.com/pl-pl/rest/api/iothub/

43.
Request:
GET https://<IoT hub domain name>/devices?api-version=2016-11-14
Response:
- status code: 200
- type: Device[]
- description: OK
Media Types: "application/json", "text/json"
Device[] - collections of Device resource
Device - has dedicated properties like: deviceId (string), deviceStatus (disabled |
enabled : string), cloudToDeviceMessageCount (integer)
REST - GET all devices
IoT
Protocols review
https://docs.microsoft.com/en-us/rest/api/iothub/deviceapi/getdevices

44.
Request:
PUT https://<IoT hub domain name>/jobs/v2/{jobid}
Request Body:
- Media Types: "application/json", "text/json"
- required: jobId (string)
- required: type (string - enum: schedule | Device | Method | Update | Twin)
- optional: queryCondition (string)
Response:
- status code: 201
- description: Created
Media Types: "application/json", "text/json"
REST - PUT create job
IoT
Protocols review
https://docs.microsoft.com/en-us/rest/api/iothub/deviceapi/getdevices

45.
Request:
PATCH https://<IoT domain name>/twins/{id}?api-version=2016-11-14
Request Body:
- Media Types: "application/json", "text/json"
- required: DeviceId (string)
- required: IsConnected (boolean)
- optional: Version (integer)
Response:
- status code: 200
- type: DeviceTwinInfo
- description: Created + Media Types: "application/json", "text/json"
REST - PATCH update twin
IoT
Protocols review
https://docs.microsoft.com/en-us/rest/api/iothub/devicetwinapi/updatedevicetwin

46.
Request:
DELETE https://<IoT domain>/devices/{id}?api-version=2016-11-14
Response:
- status code: 204
- description: NoContent
Media Types: "application/json", "text/json"
REST - DELETE device
IoT
Protocols review
https://docs.microsoft.com/en-us/rest/api/iothub/deviceapi/deletedevice

47.
Request:
PUT https://<IoT hub domain name>/iot/core/api/v1/capabilities
Request Headers:
- Content-Type : application/json
- Authorization : Basic <basic_auth_token_using_user_and_password>
Request Body:
- {"name" : "weather_property_set",
"properties" : [{
"name" : "temperature", "dataType" : "float", "unitOfMeasure" : "°C"
},{
"name" : "humidity", "dataType" : "float", "unitOfMeasure" : "%"
}
]}
Response:
- status code: 201 Created
REST - POST create sensor
IoT
Protocols review
https://blogs.sap.com/2017/08/24/how-to-create-a-iot-device-and-push-data-via-rest-with-sap-cloud-platform-internet-of-things-service-and-sap-iot-application-enablement/

48.
Text based HTTP sniffer:
https://github.com/jbittel/httpry
HTTP/REST toolbox
IoT
Protocols review
http://xmodulo.com/sniff-http-traffic-command-line-linux.html

49.
MQTT - simple protocol and message centric
- has pretty short specification
- public - subscribe (default port 1883)
- light (small, it’s binary with 2Byte header)
- ideal for exchanging data between low power
machines
- implemented data security
- has Quality Of Service
- avg. libraries size: 30KB C, 100KB Java
- data distribution: 1 to 0/1/N
MQTT vs. HTTP/REST
IoT
Protocols review
http://www.rfwireless-world.com/Terminology/MQTT-vs-HTTP.html , http://mqtt.ximxim.com/mqtt-vs-http-which-one-is-the-best-for-iot/
HTTP/REST - complex protocol and document centric
- specifications are much longer
- client - server (default port 80 or 8080)
- text based protocol (large, it is in ASCII format)
- standard communication protocol for sharing
data and information
- security only in HTTPS
- no Quality Of Service
- avg. libraries size: Large
- data distribution: one to one only

50.
MQTT vs. HTTP/REST - life
IoT
Protocols review
https://www.slideshare.net/paolopat/mqtt-iot-protocols-comparison
According to measurements in 3G networks, throughput of MQTT is 93 times faster than HTTP’s.
HTTP is worthy, well tested and extendable.
But MQTT is more suitable when it is referred to IoT development.

51.
DDS from standard to
protocol
IoT
Protocols review

52.
DDS - basics
IoT
Protocols review
- "The first open international middleware standard directly addressing
publish-subscribe communications for real-time and embedded
systems."
- DDS addresses the needs of applications like financial trading, air-traffic
control, smart grid management, and other big data applications.
- The standard is used in applications such as smartphone operating systems,
transportation systems and vehicles, software-defined radio, and by healthcare
providers.

53.
MoM - middleware concept
Message-oriented middleware (MOM) is
software or hardware infrastructure supporting
sending and receiving messages between
distributed systems.
MOM allows application modules to be
distributed over heterogeneous platforms and
reduces the complexity of developing
applications that span multiple operating
systems and network protocols.
A MOM system with built-in intelligence can
transform messages en route to match the
requirements of the sender or of the recipient.
IoT
Protocols review

54.
DDS - interoperability
The DDS interoperability demonstration used
scenarios such as:
- Basic connectivity to network using IP
- Discovery of publishers and subscribers
- Quality of service (QoS) Compatibility
between requester and offerer
- Delay-tolerant networking
- Multiple topics and instances of topics
- Exclusive ownerships of topics
- Content filtering of topic data including
time and geographicIoT
Protocols review

55.
Data-Centricity or Message-Centricity?
- In a message-centric system the focus is on
delivery of the message itself regardless of
the data payload it contains and the
infrastructure's role is to ensure that messages
get to their intended recipients.
- In a data-centric system the focus is on
user defined data (the data model). The unit
of exchange in this type of system is a data
value. The middleware understands the
context of the data and ensures that all
interested subscribers have a correct and
consistent view of the data. This is similar in
concept to a database that can provide a
global view (data space) of the data and can
manage its access.
IoT
Protocols review
Global data space

56.
- DDS supports a decentralized broker-less
architecture to enable seamless data sharing
between producers and consumers.
- DDS is based on the idea of a virtual “global
data space” where producers write to the
data space and consumers read from the
data space.
- A data model consisting of named topics,
their user defined data types and associated
QoS is used to by the DDS infrastructure to
control how data is shared.
- DDS connects producers to consumers over
the data bus
DDS Data Bus Architecture
IoT
Protocols review
DDS Data Bus Architecture

57.
DDS toolbox
IoT
Protocols review
- DDS community code examples (free)
- https://github.com/rticommunity/rticonnextdds-examples
- CoreDX DDS Spy (commercial)
- http://www.twinoakscomputing.com/datasheets/CoreDX_DDS_SpyTool_datasheet.pdf
- it can process data from industry standard network capture files (e.g. Wireshark)

58.
MQTT - simple publish-subscribe protocol
- messages delivery with Quality of Service is the most
important
- communication by one point: Message Broker
- Message Broker is the SPoF
- data messages routed by topics
- for collecting data from few systems with sensors
network
- usage in telemetry: device to server, data center, ITcloud
- centralized & server based analytics, business logic and
integration
MQTT vs. DDS
IoT
Protocols review
http://www.rfwireless-world.com/Terminology/MQTT-vs-HTTP.html , http://mqtt.ximxim.com/mqtt-vs-http-which-one-is-the-best-for-iot/
DDS - data-centric standard
- data sharing (visiblility for consumers) is the most
important
- communication is peer-to-peer
- decentralized (no SPoF’s)
- distributed, manage tiny devices
- reliable, high-performance architecture for
connecting many systems with different networks
- usage in Intelligent Systems: within and
between devices, dedicated systems, real-time
cloud, analytics, biz logic & integration
distributed, embedded, at edge

59.
MQTT vs. DDS requirements
IoT
Protocols review
https://www.slideshare.net/RealTimeInnovations/comparison-of-mqtt-and-dds-as-m2m-protocols-for-the-internet-of-things

60.
MQTT vs. DDS - QoS differences
IoT
Protocols review
https://www.slideshare.net/RealTimeInnovations/comparison-of-mqtt-and-dds-as-m2m-protocols-for-the-internet-of-things

61.
IoT protocols war !
HTTP
AMQP
DDS
STOMP
CoAP
MQTT
XMPP
Thread
Bluetooth
Zigbee
Z-Wave
6LowPAN
WiFi
Sigfox
Neul
LoRaWANIoT
Protocols review

62.
IoT protocols distribution
Rather than trying to fit all of the IoT Protocols on top of existing architecture
models like OSI Model, we have broken the protocols into the following layers
to provide some level of organization:
1. Infrastructure (ex: 6LowPAN, IPv4/IPv6, RPL, UDP, DTLS)
2. Identification (ex: EPC, uCode, IPv6, URIs)
3. Comms / Transport (ex: NFC, Wifi, Bluetooth, LoRaWAN, NB-IoT)
4. Discovery (ex: Physical Web, mDNS, DNS-SD, HyperCat)
5. Data Protocols (ex: MQTT, CoAP, AMQP, Websocket, DDS, HTTP)
6. Device Management (ex: TR-069, OMA-DM)
7. Semantic (ex: JSON-LD, Web Thing Model, SensorML)
8. Multi-layer Frameworks (ex: Alljoyn, IoTivity, Weave, Homekit, Thread)
IoT
Protocols review
https://www.postscapes.com/internet-of-things-protocols/

63.
IoT architectures
- domains
- platform
- gateways
- integrations
- clouds
IoT
Protocols review
https://www.researchgate.net/figure/High-level-IoT-architecture_fig1_281896657

64.
IoT architectures (domains)
IoT
Protocols review
https://www.researchgate.net/figure/High-level-IoT-architecture_fig1_281896657

65.
IoT architectures (platform)
IoT
Protocols review
https://www.linkedin.com/pulse/iot-architecture-edge-rafael-rocha

66.
Gateway
IoT
Protocols review
https://www.slideshare.net/RealTimeInnovations/comparison-of-mqtt-and-dds-as-m2m-protocols-for-the-internet-of-things

67.
Integrate DDS into the Broker/ESB
IoT
Protocols review
https://www.slideshare.net/RealTimeInnovations/comparison-of-mqtt-and-dds-as-m2m-protocols-for-the-internet-of-things

68.
Dual Clouds
IoT
Protocols review
https://www.slideshare.net/RealTimeInnovations/comparison-of-mqtt-and-dds-as-m2m-protocols-for-the-internet-of-things

69.
IoT implementation steps
STEP-1: Look at the use cases that are relevant to the domain or industry you
operate in.
STEP-2: Think of ways to enhance those use cases to increase your Reach,
Accuracy, Customer Satisfaction, Retention or Cross-sell opportunities.
STEP-3: Analyze the impact and compatibility of existing Processes and
Systems.
STEP-4: Identify the IoT platform and Skills required to implement and carry
out maintenance activities.
STEP-5: Identify the “Things” required and technical aspects like protocols.
IoT
Protocols review
https://www.linkedin.com/pulse/point-of-view-role-bpm-internet-things-iot-yusufzai-s-khan

70.
1. marcinbielak.blogspot.com - my private tech. blog
2. IoT Standards and Protocols
3. Mesh vs star topology diagram from slides, slides
4. Understanding IoT cloud
5. Key Standarization Activities
6. MQTT telemetry transport
7. Power Profiling: HTTPS Long Polling vs. MQTT with
SSL, on Android
References