IoT Protocols

Outline
1. IoT Architecture
2. IoT Protocol Stack
3. Bluetooth
4. ZigBee
5. 6LoPAN
6. LoRa
7. MQTT - Message Queueing Telemetry Transport
8. CoAP - Constrained Application Protocol
9. XMPP - eXtensible Messaging and Presence Protocol
10. Protocol Implementation
11. IoT Communication APIs
IoT Architecture
IoT Broker Architecture
IoT Protocol Stack : Standardized IoT Protocols
Radio Communication
• Electromagnetic Waves
• No medium required
• Modulation
• Well described mystery
• Wireless/Airwaves
• Inverse Square Law
 Bluetooth
• Bluetooth is a network technology that connects mobile devices wirelessly over a short-range to form a personal area network (PAN).
• A cable replacement technology.
• Developed by Ericsson-1994.
• Operates in the unlicensed industrial, scientific and medical (ISM) band at 2.4 GHz
• Frequency Hopping scheme (1600 hops/sec)
• 1 Mb/s symbol rate
• Range 10+ meters
• Single chip radio + baseband
• Key features:
• Robustness
• low complexity
• low power, and
• low cost.
• It is a significant protocol for IoT applications.
 Bluetooth Applications
• In laptops, notebooks and wireless PCs
• In mobile phones and PDAs (personal digital assistant).
• In printers.
• In wireless headsets.
• In wireless PANs (personal area networks) and even LANs
(local area networks)
• To transfer data files, videos, and images and MP3 or MP4.
• In wireless peripheral devices like mouse and keyboards.
• In data logging equipment.
• In the short-range transmission of data from sensors devices
to sensor nodes like mobile phones.
• Physical Layer − This includes Bluetooth radio
and Baseband (also in the data link layer.
• Radio − This is a physical layer equivalent
protocol that lays down the physical
structure and specifications for
transmission of radio waves. It defines air
interface, frequency bands, frequency
hopping specifications, and modulation
techniques.
• Baseband − This protocol takes the services
of radio protocol. It defines the addressing
scheme, packet frame format, timing, and
power control algorithms.
• Data Link Layer − This includes Baseband, Link Manager Protocol (LMP), and Logical Link Control and
Adaptation Protocol (L2CAP).
• Link Manager Protocol (LMP) − LMP establishes logical links between Bluetooth devices and
maintains the links for enabling communications. The other main functions of LMP are device
authentication, message encryption, and negotiation of packet sizes.
• Logical Link Control and Adaptation Protocol (L2CAP) − L2CAP provides adaption between upper
layer frame and baseband layer frame format. L2CAP provides support for both connection-oriented
as well as connectionless services.
• Middleware Layer
• RFComm − It is short for Radio Frontend Component. It provides a serial interface with WAP.
• Adopted Protocols − These are the protocols that are adopted from standard models. The commonly
adopted protocols used in Bluetooth are Point-to-Point Protocol (PPP), Internet Protocol (IP), User
Datagram Protocol (UDP), Transmission Control Protocol (TCP), and Wireless Application Protocol
(WAP).
• Service Discovery Protocol (SDP)− SDP takes care of service-related queries like device information so
as to establish a connection between contending Bluetooth devices.
• AT Commands − ATtention command set.
• Applications Layer − This includes the application profiles that allow the user to interact with the
Bluetooth applications.
HC-05 6pin Bluetooth Module
802.15.4
• Low Power
• Low bandwidth
• Addressing
• Affordable
• Small
• Standardized
• Popular
802.15.4 Configurations
• Single Peer

• Multi Peer

• Broadcast
 802.15.4 Architecture

Applications

ZigBee

IEEE 802.15.4 MAC

IEEE 802.15.4 IEEE 802.15.4

868/915 MHz 2400 MHz
PHY PHY
 Zigbee
• Layer on top of 802.15.4
• ZigBee is similar to Bluetooth and is majorly used in industrial settings.
• It has some significant advantages in complex systems offering low-power operation,
high security, robustness and high and is well positioned to take advantage of wireless
control and sensor networks in IoT applications.
• Zigbee - set of high level communication protocols based upon the specification
produced by 802.15.4
• IEEE 802.15.4 - Standard released in May 2003 for LR-WPAN-Low-Rate Wireless Personal
Area Network (LR-WPAN)
• Routing (pass messages on)
• Ad-hoc network creation
• Self-healing
• The ZigBee Alliance is an association of companies working together to enable reliable,
cost-effective, low-power, wirelessly networked, monitoring and control products based
on an open global standard.
 Zigbee Configurations

• Star

• Mesh
 • Whip
Antennas
• Chip

• RPSMA
• u.FL
Regular vs. Pro
• 1-2mW • 50-60mW
• Smaller • Longer
• Shorter range (100m) • Longer range (300m)
• Cheaper
• More expensive
ZigBee Stack Architecture :

Chaitanya Misal, Vamsee Krishna

 ZigBee Applications
security
HVAC TV
AMR VCR
lighting control DVD/CD
access control BUILDING
AUTOMATION
ZigBee CONSUMER
ELECTRONICS
remote
Wireless Control
that
patient Simply Works
monitoring mouse
fitness keyboard
monitoring PERSONAL HEALTH joystick
CARE PC & PERIPHERALS

TELECOM SERVICES
asset mgt security
process HVAC
control m-commerce lighting control
environmental INDUSTRIAL
CONTROL info services HOME CONTROL
access control
energy mgt object interaction (Internet of irrigation
Things) Slide 19
Comparison with peer technologies!

Chaitanya Misal, Vamsee Krishna

Simple ZigBee for Arduino & XBee
What is 6LoWPAN?
• IPv6 over Low-Power wireless Area Networks (LoWPAN)
• LowPAN = LLN?
• Defined by IETF standards
• Stateless header compression
• Enables a standard socket API
• Minimal use of code and memory
• Direct end-to-end Internet integration
• Multiple topology options
Protocol Stack
 Architecture
Device types
• H Host
• R Router
• ER Edge router

Edge router
• Runs special protocols
• Simplifies operation
• Shared database: Whiteboard

Internet Integration issues

• Maximum transmission unit (1500 vs 127 bytes)
• Application protocols
• IPv4 interconnectivity
• Firewalls and NATs
• Security
LoRa and LoRaWAN
• LoRa VS LoRaWAN
LoRa contains only the link layer protocol and is perfect to be used in P2P communications
between nodes. LoRa modules are a little cheaper that the LoRaWAN ones.
• It works in the 868 and 900MHz bands.
• LoRaWAN includes the network layer too so it is possible to send the information to any Base
Station already connected to a Cloud platform. LoRaWAN modules may work in the
868/900/433MHz bands.
• Advantages:
• Long Range: LoRa devices can transmit signals over distances from 1km — 10km.
• Low Power: LoRa end nodes wake up only at a fixed time, which can extend battery life. End
node batteries can last for 5-10 years.
• Security: Data encryption using AES128 between end nodes and network servers/ Data
encryption using AES128 at the application level.
• Low Cost: Work in free frequencies and no upfront licensing cost to use the technology. 6)
Easy Deployment: Simple network architecture and easy to deploy by yourself.
• Disadvantages:
• Not for large data transmission.
• Not for continuous monitoring.
• Wake up only at a fixed time, so you can’t communicate with end nodes at any time.
• The transmission rate is slow and easy to get interference because of using free frequencies.
IoT Protocols
• Infrastructure (ex: 6LowPAN, IPv4/IPv6, RPL)
• Identification (ex: EPC, uCode, IPv6, URIs)
• Comms / Transport (ex: Wifi, Bluetooth, LPWAN)
• Discovery (ex: Physical Web, mDNS, DNS-SD)
• Data Protocols (ex: MQTT, CoAP, AMQP, Websocket, Node)
• Device Management (ex: TR-069, OMA-DM)
• Semantic (ex: JSON-LD, Web Thing Model)
• Multi-layer Frameworks (ex: Alljoyn, IoTivity, Weave, Homekit)
IoT Protocol Stack
IoT Communication Models
• Request – Response
• Publish – Subscribe
• Push-Pull
• Exclusive Pair
IoT Messaging Protocols
IoT Messaging Protocols
IoT Messaging Protocols
IoT Messaging Protocols
Application layer protocols main features
comparison
MQTT - Message Queueing Telemetry Transport
MQTT in the world of IoT

43
MQTT interaction model

44
MQTT in Short
• MQTT is a Client Server publish/subscribe messaging
transport protocol
• More features:
• Simple to implement (especially at the sensor side)
• QoS Support
• Lightweight and bandwidth efficient and Data agnostic
• Session awareness

45
MQTT Architecture
MQTT Communication Pattern
Publish/Subscribe paradigm
•Clients don’t know each other
• One-to-Many paradigm
•Every client publishes & subscribes
•PUSH information paradigm compared to PULL’s one in COAP

47
MQTT Components
• Broker and connected Clients
• broker receives subscriptions from clients on
topics
• broker receives messages and forward them
• clients subscribe/publish on topics
• Brokers bridge configuration
MQTT Packet Format
MQTT Open Connection

CONNECT
message fields:
 MQTT Publishing

PUBLISH
message fields:
MQTT QoS 0: “at most once”

Best effort transfer (same reliability

provided by the underlying transport
protocol)
MQTT QoS 1: “at least once”

The MQTT client stores the message

and keeps retransmitting it until it is
acknowledged by the MQTT broker
(message can be received multiple
times)
MQTT QoS 2: “exactly once”

QoS 2 is the highest level of service in MQTT.

This level guarantees that each message is
received only once by the intended recipients.
QoS 2 is the safest and slowest quality of
service level.
MQTT Last Will Message
• The Last Will and Testament (LWT) notifies other clients about an
hard disconnect by a specific client
• Each client can specify its last will message when connecting to a
broker
• The broker will store the message until it detects client hard
disconnection
• The broker sends the message to all subscribed clients on the specific
topic
• The stored LWT message will be discarded if a client disconnects
gracefully by sending a DISCONNECT message.

55
MQTT for Sensor Networks – MQTT-SN
• Uses UDP
• Supports topic name indexing
• Reduced size of the payloads (by numbering the data packets with
numeric topic id’s rather than long topic names)

Disadvantage: MQTT-SN is only supported by a few platforms, and

there is only one free broker implementation known, called Really
Small Message Broker

56
Getting Started with MQTT
• MQTT protocol brokers:
• Mosquitto
• HiveMQ
• Emqttd
• ActiveMQ
• IBM MessageSight
• JoramMQ
• RabbitMQ
• VerneMQ

Clients are realized by installing MQTT client libraries

57
MQTT Summary
• MQTT is a publish/subscribe messaging protocol designed for
lightweight M2M communications. It was originally developed by IBM
and is now an open standard.
• MQTT has a client/server model, where every sensor is a client and
connects to a server, known as a broker, over TCP.
• MQTT is message oriented. Every message is a discrete chunk of data,
opaque to the broker.
• Every message is published to an address, known as a topic. Clients
may subscribe to multiple topics. Every client subscribed to a topic
receives every message published to the topic.
58
CoAP - Constrained Application Protocol
CoAP Architecture

60
CoAP at a Glance

• Embedded web transfer protocol (coap://)

• Based on REST architecture (client-server, stateless, cacheable)
• Asynchronous transaction model
• UDP binding with reliability and multicast support of GET, POST,
PUT, DELETE methods
• URI support
• 4 byte header
• Subset of MIME types and HTTP response codes o Built-in
discovery
• Optional observation and block transfer

61
COAP using GET and RESTful URLs

62
HTTP vs. CoAP

63
CoAP Messaging Basics
• Transport:
• (mainly) UDP binding
• Message Exchange between Endpoints
• Messages with 4 bytes header (shared by request and
responses) containing a message ID (16 bits)
• Reliable exchange through Confirmable Messages which must
be acknowledged (through ACK or Reset Messages). Simple
Stop-and-Wait retransmission with exponential back-off.
• Unreliable exchange through Non-Confirmable Message
• Duplicate detection for both confirmable and non-confirmable
messages (through message ID)

64
CoAP Message Format

Ver - Version (1)

T – Message Type (Confirmable, Non-Confirmable, Acknowledgement, Reset)
TKL- Token Length, if any, the number of Token bytes after this header
Code - Request Method (1-10) or Response Code (40-255)
Message ID – 16-bit identifier for matching responses
Token – Optional response matching token
CoAP Messaging

66
CoAP Message Semantics
CoAP Request and Response
CoAP Request and Response Example
CoAP Separate Response Example
CoAP Non-confirmable Request Example
CoAP Dealing with Packet Loss

• Stop and Wait approach

• Repeat a request after a time-out in case ACK (or RST) is not coming
back
CoAP Observation
• PROBLEM:
• REST paradigm is often “PULL” type, that is, data is
obtained by issuing an explicit request
• Information/data in WSN is often periodic/triggered (e.g.,
get me a temperature sample every 2 seconds or get me a
warning if temperature goes below 5°C)
• SOLUTION: use Observation on COAP resources
CoAP Observer Mode
CoAP Security

• DTLS (Datagram Transport Layer Security) is used by CoAP as the security

protocol
• For key management and data encryption and integrity protection.

• CoAP with DTLS support is similar to HTTPs.

• Problem: DTLS is inefficient for constrained IoT devices.

• Solution: Apply the 6LoWPAN header compression mechanisms to compress DTLS header.

75
CoAP vs MQTT
• MQTT is a many-to-many communication protocol for passing messages between
multiple clients through a central broker. It decouples producer and consumer by letting
clients publish and having the broker decide where to route and copy messages. While
MQTT has some support for persistence, it does best as a communications bus for live
data.
• CoAP is, primarily, a one-to-one protocol for transferring state information between
client and server. While it has support for observing resources, CoAP is best suited to a
state transfer model, not purely event based.
• MQTT clients make a long-lived outgoing TCP connection to a broker. This usually
presents no problem for devices behind NAT. CoAP clients and servers both send and
receive UDP packets. In NAT environments, tunnelling or port forwarding can be used to
allow CoAP, or devices may first initiate a connection to the head-end as in LWM2M.
• MQTT provides no support for labelling messages with types or other metadata to help
clients understand it. MQTT messages can be used for any purpose, but all clients must
know the message formats up-front to allow communication. CoAP, conversely, provides
inbuilt support for content negotiation and discovery allowing devices to probe each
other to find ways of exchanging data.

76
Getting Started with CoAP
• Open source implementations:
• Java CoAP Library Californium
• C CoAP Library Erbium
• libCoAP C Library
• jCoAP Java Library
• OpenCoAP C Library
• TinyOS and Contiki include CoAP support
• Firefox has a CoAP plugin called Copper
• Wireshark has CoAP plugin

77
CoAP Summary
• Like HTTP, CoAP is a document transfer protocol. Unlike HTTP, CoAP is designed for the
needs of constrained devices.
• CoAP packets are much smaller than HTTP TCP flows. Bitfields and mappings from strings
to integers are used extensively to save space. Packets are simple to generate and can be
parsed in place without consuming extra RAM in constrained devices.
• CoAP runs over UDP, not TCP. Clients and servers communicate through connectionless
datagrams. Retries and reordering are implemented in the application stack. Removing
the need for TCP may allow full IP networking in small microcontrollers. CoAP allows
UDP broadcast and multicast to be used for addressing.
• CoAP follows a client/server model. Clients make requests to servers, servers send back
responses. Clients may GET, PUT, POST and DELETE resources.
• CoAP is designed to interoperate with HTTP and the RESTful web at large through simple
proxies.
• Because CoAP is datagram based, it may be used on top of SMS and other packet based
communications protocols.

78
XMPP - eXtensible Messaging and Presence Protocol
Who uses XMPP?
• Cisco Webex
• WhatsApp uses a trimmed down version
• Google’s Firebase and Google’s Android
XMPP
• Bi-directional streaming XML
• Core: IETF RFC 3920, 3921
• Extensions: XMPP Standards Foundation (XSF)
• Membership-based
• Elected technical council
• Unit of work: XMPP Extension Protocol (XEP)
• Process: Experimental, Proposed, Draft, Final
• Goals:
• Simple clients
• Federate everything
XMPP was originally named Jabber

• Jabber is best known as “the Linux of instant messaging”

• It is an open, secure, ad-free alternative to consumer instant
messaging services like AIM, ICQ, MSN, and Yahoo.
• Under the hood, Jabber is a set of streaming XML protocols
and technologies that enable any two entities on the
Internet to exchange messages, presence, and other
structured information in close to real time. (Jabber.org)
XMPP From IETF
• In IM, the central point of focus is a list of one's contacts or "buddies" (in XMPP this list is
called a "roster").
• The purpose of using such an application is to exchange relatively brief text messages
with particular contacts in close to real time -- often relatively large numbers of such
messages in rapid succession, in the form of a one-to-one "chat session" The catalyst for
exchanging messages is "presence" -- i.e., information about the network availability of
particular contacts (thus knowing who is online and available for a one-to-one chat
session).
• Presence information is provided only to contacts that one has authorized by means of
an explicit agreement called a "presence subscription".
• Thus at a high level XMPP needs to be able to complete the following use cases:
• Manage items in one's contact list (list is maintained on the server)
• Exchange messages with one's contacts
• Exchange presence information with one's contacts (send communication status to the server)
• Manage presence subscriptions to and from one's contacts
XMPP
• IETF Standard since 2004
• Open and free – supported by the XMPP Standards Foundation (XSF)
• Created by Jeremy Miller in 1998 – originated as Jabber - multi user chat
• Has been extended in many ways over the years, supports Pub/Sub
• Designed for client server instant messaging but with no central authority
• Architecture similar to email – anyone can run an XMPP server
• May be isolated on a local intranet or may be public
• All about sending XML messages over a network to do a wide variety of
things. An XMPP message may be used to communicate between people (a
chat application) or might be used by a sensor to report on its state.
 XMPP Architecture
• Addressing Scheme: node@domain/resource
• JID = Jabber ID
• Node: identity, e.g. user name
• Domain: DNS domain name
• Resource: device identifier
• node@domain identifies a person
• Client talks to “local” server
• Wherever the user account is hosted
• Tied to directory if desired
• Organizational policy enforced
• Servers talk to other servers
• DNS lookup on domain portion of address
• Dialback, MTLS for security
• One connection for many conversations
XMPP Architecture
Naming Things (1)
• A lot like an email address , XMPP uses Jabber ID’s (JIDs)
• All of these JIDs could be logged on at the same time.
• mm6@andrew.cmu.edu Called a “bare JID”
• mm6@andrew.cmu.edu/mobile Includes a resource. This is called a “full JID”
• mm6@andrew.cmu.edu/tablet Resource used for message delivery
• mm6@andrew.cmu.edu/auto Resource typically assigned by server
• On Whatsapp: 412-776-1212@s.whatsapp.net
• You may only subscribe to bare JIDS.
• A resource identifies a particular client belonging to the user
• A user can log in to an XMPP server multiple times, and in this case, the resource
can denote a location. For example, the sample user might have a JID for his
main terminal (DavidBowman@discovery.nasa.guv/terminal) and another JID
(session) from an EVA pod (DavidBowman@discovery.nasa.guv/eva_pod1). So, a
particular location can be targeted or left absent to reach the user at whichever
location he happens to be logged in.
Naming Things (2)
• The resource may be a random string
• Each connection is bound to a specific resource
• Many clients may use the same account at the same time. To send a message to
one of them you must have the full JID.
• Only “friends” may communicate with each other.
• Suppose Alice makes a request for a presence subscription to Bob’s bare JID.
• If Bob agrees, Alice will receive Bob’s full JID along with presence status (online,
offline, etc.)
• Suppose Bob makes a request for a presence subscription to Alice’s bare JID.
• If Alice agrees, Alice and Bob are now friends. Both each have the other’s full JID.
XMPP Security Stuff
• Start-TLS
• Prove the identity of the server
• Prove the identity of the user (optional)
• Encryption
• Data integrity
• SASL (RFC 4422)
• Authentication
• Optional encryption (rarely used)
• Pluggable (e.g. passwords, Kerberos, X.509, SAML, etc.)
XMPP Summary
• XMPP was developed for instant messaging (IM) to connect people to other people via text
messages.
• XMPP uses the XML text format as its native type, making person-to-person communications
natural.
• XMPP runs over HTTP on top of TCP. Its key strength is a name@domain.com addressing scheme
that helps connect the needles in the huge Internet haystack.
• In the IoT context, XMPP offers an easy way to address a device. This is especially handy if that
data is going between distant, mostly unrelated points, just like the person-to-person case. It’s
not designed to be fast. In fact, most implementations use polling, or checking for updates only
on demand.
• A protocol called BOSH (Bidirectional streams over Synchronous HTTP) lets severs push
messages.
• XMPP response time is in seconds and it is good for people to people communication
• XMPP provides a great way, for instance, to connect your home thermostat to a Web server so
you can access it from your phone. Its strengths in addressing, security, and scalability make it
ideal for consumer-oriented IoT applications.

90
Protocol Implementation
Protocol Implementation
IoT Communication APIs
• REST – based Communication APIs
• WebSocket – based Communication APIs
REST-based Communication APIs
• Representational State Transfer (REST) is a set of architectural
principles by which you can design web services and web APIs that
focus on a system’s resources and how system resource states are
addressed and transferred
• REST APIs follow the request-response communication model
• The REST architectural constraints apply to the components,
connectors, and data elements within a distributed hypermedia
system
REST Architectural Constraints
• Client –Server
• The principle behind the client-server constraints is the separation of
concerns
• Stateless
• Each request from client to server must contains all the information
necessary to understand the request
• The session state is kept entirely on the client
• Cache-able
• Cache constraints requires that the data within a response to a request be
implicitly or explicitly labeled as cache-able or non-cache-able
REST Architectural Constraints
• Layered System
• Layered system constraints, constraints the behavior of components such
that each component cannot see beyond the immediate layer with which
they are interacting
• Uniform Interface
• Interface constraints requires that the method of communication between a
client and a server must be uniform
• Code on demand
• Servers can provide executable code or scripts for clients to execute in their
context
WebSocket-based Communication APIs
• WebSocket APIs allow bi-directional, full duplex communication
between clients and servers
• It follows the exclusive pair communication model
• WebSocket APIs reduce the network traffic and latency as there is no
overhead for connection setup and termination requests for each
message