Syllabus

Protocols for loT -Types of protocols based on functionality, infrastructure protocol IPV4/V6,
Identification (URLs), Connectivity protocols-(6LowPAN, RPL), Transport/Communication
protocols- WIFI, LiFi, BLE, NFC, Data protocols-(MQTT, CoAP, XMP), A cases study with
MQTT/CoAP usage

Protocols for IoT

One of the main pillars of IoT is its connectivity. It consists of a huge network of elements,
both objects and people of different sizes and shapes, which are connected to gather and
share information. In general, the information is gathered and used to automate or help
make decisions. Due to the variety of data types and applications, different communication
and network protocols are needed.

Protocols are a set of rules for transmitting data between electronic devices according to a
preset agreement regarding information structure and how each side will send and receive data.
Correspondingly, IoT protocols are standards that enable the exchange and transmission of
data between the Internet and devices at the edge.

IoT protocols can be divided into two categories: IoT network protocols and IoT data protocols. Data
protocols mainly focus on information exchange, while network protocols provide methods of
connecting IoT edge devices with other edge devices or the Internet. Each category contains a number
of protocols that each have their own unique features. We'll take a look at those next.

List of Common IoT Protocols

IoT Network Protocols

Wi-Fi:- Wi-Fi is a ubiquitous protocol that can be found almost anywhere—industrial plants, homes,
commercial buildings, and even your neighborhood restaurants. This widely favored technology is
able to transmit large volumes of data over reasonable distances. However, many low-power or
battery-powered IoT devices are unlikely to use Wi-Fi due to its high power consumption rate.

Read our in-depth comparison of cellular vs. WiFi for IoT applications to learn more about when
WiFi makes sense and when it doesn’t.

LTE CAT 1:- LTE CAT 1 is a communication standard specifically designed for servicing IoT
applications. Compared with other standards, it scales down bandwidth and communication demand
to save power and cost for large-scale and long-range IoT systems. Though LTE CAT 1 performs
inferiorly to 3G networks, experts predict that it will replace 3G as major U.S. carriers sunset 3G in
2022.

LTE CAT M1:-LTE CAT M1—which can also be referred to as Cat-M—is a low-cost, low-power,
wide-area network that specializes in transferring low to medium amounts of data. It was developed
by the 3rd Generation Partnership Project as part of the 13th edition of LTE standard and is a
core cellular IoT technology.

Cat-M stands out as a protocol option because it is compatible with the prevailing LTE network,
meaning major carriers pivoting to it will not have to invest in new antennas.

Comparison: CAT M1 is considered a complementary technology to NB IoT. However, CAT M1 has

a faster upload/download speed of 1 Mbps and a lower latency of 10 to 15 ms.

NB-IoT:- While the protocols detailed previously have been in application for a long time, Narrow
Band-IoT is a new, fast-growing, low-power, wide-area technology intended to specifically target the
needs of battery-powered IoT devices.

When compared to other cellular protocols, NB-IoT's advantages include improvements in power
consumption, system capacity, and spectrum efficiency. For example, NB-IoT can connect huge fleets
with up to 50,000 devices per network cell.

However, NB-IoT doesn’t come without challenges. The protocol has very limited bandwidth, which
can slow or limit data transmission capabilities and make essential features like over-the-air updates
difficult or impossible to achieve. Also, the protocol has seen limited rollout and support in
worldwide geographies. While support is growing, fragmented availability is a risk to any IoT
deployment.

Bluetooth:- Bluetooth focuses on point-to-point, short-range communication of a relatively small

amount of data. In the IoT space, Bluetooth is commonly used to connect small, battery-powered
sensors to IoT gateways or to facilitate communication with a smartphone, eBike, or other smart
device.

ZigBee:-Ratified in the early 2000s, ZigBee stands out as a low-cost, low-power, and reliable wireless
network technology. The standard is adaptable and supports multiple network topologies, including
mesh networks, point-to-multipoint, and point-to-point. ZigBee is most commonly used in home or
building automation settings.
LoRaWAN:- Long-range wide area network—also referred to as LoRa—is a long-range, radio-wide
networking protocol with low power consumption. Normally, LoRaWAN wirelessly connects
multiple battery-operated devices to the Internet within regional, national, or global networks.

In the IoT field, LoRaWAN plays an important role in bidirectional communication, end-to-end
security, localization, and mobility services.

IoT Data Protocols

AMQP:- Known for its reliability and interoperability, Advanced Message Queuing Protocol is an
open messaging standard. This protocol utilizes queues of data, enabling connected systems to
communicate asynchronously and better handle issues like traffic spikes and poor network conditions.

Additional AMQP features include durable and persistent queues, federation and high-availability
queues, clustering, and flexible routing. However, AMQP is known to be a verbose protocol in some
circumstances.

MQTT:- Message Queue Telemetry Transport is a lightweight pub/sub messaging protocol suitable
for connecting small, low-power devices.

This data protocol was designed specifically for IoT communication and requires minimal memory
and processing power. On the wire, MQTT's bidirectional pub/sub architecture makes the protocol
flexible and scalable for a wide variety of use cases and IoT system architectures.

Additionally, the MQTT protocol is designed with reliability and scalability in mind—security is
provided via Transport Layer Security, and persistent sessions allow the protocol to adapt to poor
network conditions and reduce connection time overhead.

HTTP:- You might recognize this acronym as appearing at the beginning of every website address
you type, as Hypertext Transfer Protocol is the foundation of data communication for the World Wide
Web.

However, within the context of IoT applications, HTTP has many drawbacks. For instance, this
protocol establishes a synchronous connection between two devices in order to transfer data—which
presents a number of challenges for IoT deployments because devices and endpoints may not be
online at the same time and connections may be unreliable due to network conditions.
Additionally, HTTP relies on transferring data in ASCII, which is an inefficient way to transmit the
small bits of data often exchanged by IoT systems and requires more processing power to encode and
decode messages at both ends.

Ultimately, while HTTP is a great choice for transferring website data, it is generally not a good
choice for an IoT application.

CoAP:- Constrained Application Protocol is used with constrained nodes and networks. This protocol
is suited for IoT applications as it reduces the size of network packages, thereby decreasing network
bandwidth overload. Other benefits of CoAP include improving the IoT life cycle, saving battery
power and storage space, and reducing the amount of data required to operate.

DDS:- Released in 2004, Data Distribution Service is a middleware architecture for real-time systems
that focus on data communication between the nodes of a publication- or subscription-based
messaging architecture.

DDS is mainly used under circumstances that require real-time data exchange—for example,
autonomous vehicles, power generation, and robotics.

LwM2M:- Lightweight Machine-to-Machine protocol is designed for remote management of M2M

devices and related services. LwM2M reduces costs associated with low-power module deployment
and equipping devices with faster IoT solutions

Identification (URLs)

URL (Uniform Resource Locator) is often defined as a string of characters that is directed
to an address. It is a very commonly used way to locate resources on the web. It provides a
way to retrieve the presentation of the physical location by describing its network location
or primary access mechanism.
The protocol is described within the URL which is employed to retrieve the resource and
resource name. The URL contains http/https at the start if the resource may be a web type
resource. Similarly, it begins with ftp if the resource may be a file and mailto if the
resource is an email address. The syntax of an URL is shown below where the primary
part is employed for protocol and the remainder of the part is employed for the resource
which consists of a website name or program name.
URI (Uniform Resource Identifier):
Similar to URL, URI (Uniform Resource Identifier) is also a string of characters that
identifies a resource on the web either by using location, name or both. It allows uniform
identification of the resources. A URI is additionally grouped as a locator, a name or both
which suggests it can describe a URL, URN or both. The term identifier within the URI
refers to the prominence of the resources, despite the technique used.
The former category in URI is URL, during which a protocol is employed to specify the
accessing method of the resource and resource name is additionally laid out in the URL. A
URL may be a non-persistent sort of the URI. A URN is required to exist globally unique
and features a global scope.

Difference between URL and URI:

URL URI

URL is used to describe the identity of an item. URI provides a technique for defining
the identity of an item.

URL links a web page, a component of a web page or URI is used to distinguish one
a program on a web page with the help of accessing resource from other regardless of the
methods like protocols. method used.

URL provides the details about what type of protocol URI doesn’t contains the protocol
is to be used. specification.
URL URI

URL is a type of URI. URI is the superset of URL.

It comprises of protocol, domain, path, hash, and so It comprises of scheme, authority,

on. path, query and many more.

Ex-https://www.geeksforgeeks.org/ Ex- urn:isbn:0-294-56559-3

Connectivity protocols-(6LowPAN, RPL)

6LowPAN
IPv6 over Low Power Wireless Personal Area Networks: 6LoPAN is an Open source protocol for
connecting devices and services in the internet of things. It enables devices to communicate with each
other and with services over the network.
6LoWPAN Features
 IETF recommended methods for reassembly of fragments
 IPv6 and UDP (or ICMP) headers compression (6LoWPAN-hc adaptation layer)
 Neighbour discovery (6LoWPAN-nd adaptation layer) and
 supports mesh routing

Issues:
1. IPv6 address formation : 128-bit IPv6 from 64-bit EUI64
2. Maximum Transmission Unit (MTU): IPv6 at least 1280 bytes vs. IEEE 802.15.4 standard packet
size is 127 bytes

3. Address Resolution: 128b or 16B IPv6 addresses. 802.15.4 devices use 64 bit (no network prefix)
or 16 bit addresses
4. Optional mesh routing in data link layer. Need destination and intermediate addresses
5. MAC-level re-transmissions versus end-to-end: Optional hop-by-hop ack feature of 802.15.4 is
used but the max number of re-transmissions is kept low (to avoid overlapping L2 and L4 re-
transmissions)
6. Extension Headers: 8b or less Shannon-coded dispatch
==> header type 
102: Mesh addressing header (2-bit dispatch)
11x002: Destination Processing Fragment header (5-bit)
010100002: Hop-by-hop Low Pan Broadcast header (8- bit)
7. IPv6 and UDP header compression

6LowPAN Broadcast Header 6

For Mesh broadcast/multicast
A new sequence number is put in every broadcast message by the originator

6LowPAN Fragment Header 6LowPAN Fragment Header

Dispatch = 11x00 (5 bits)  Fragment Header
Full packet size in the first fragment’s fragment header
Datagram tag = sequence number 
==>Fragments of the same packet
Fragment Offset in multiples of 8 bytes

Routing Protocol for Low Routing Protocol for Low-Power and Lossy Power and Lossy
Networks (RPL)
 Developed by IETF Routing over Low-Power and Lossy Networks (ROLL) working group
 Low-Power and Lossy Networks (LLN) Routers have constraints on processing, memory, and
energy. 
 ==> Can’t use OSPF, OLSR, RIP, AODV, DSR, etc
 LLN links have high loss rate, low data rates, and instability 
 expensive bits, dynamically formed topology
 Covers both wireless and wired networks Requires bidirectional links. May be
symmetric/asymmetric.
 Ideal for n-to-1 (data sink) communications, e.g., meter reading 1-to-n and 1-to-1 possible with
some extra work.
 Multiple LLN instances on the same physical networks

RPL Concepts
Directed Acyclic Graph (DAG): No cycles

 Root: No outgoing edge

 Destination-Oriented DAG (DODAG): Single root

 Up: Towards root  Down: Away from root

 Objective Function: Minimize energy, latency, …
 Rank: Distance from root using specified objective
 RPL Instance:

 One or more DODAGs. A node may belong to multiple RPL instances.

 DODAG ID: IPv6 Adr of the root
 DODAG Version: Current version of the DODAG. Every time a new DODAG is computed with
the same root, its version incremented
 Goal: Reachability goal, e.g., connected to database
 Grounded: Root can satisfy the goal
 Floating: Not grounded. Only in-DODAG communication.
 Parent: Immediate successor towards the root
 Sub-DODAG: Sub tree rooted at this node
 Storing: Nodes keep routing tables for subDODAG
 Non-Storing: Nodes know only parent. Do not keep a routing table.
RPL Data Forwarding RPL Data Forwarding
 Case 1: To the root (n-to-1)  Address to root and give to parent
 Case 2: A to B  2A: Storing (Everyone keeps a routing table)
 Forward up from A to common parent
 Forward down from common parent to B  2B: Non-storing (No routing tables except at root)
 Forward up from A to root
 Root puts a source route and forwards down
 Case 2: Broadcast from the root (1-to-n)  2A: Storing (everyone knows their children)
 Broadcast to children  2B: Non-Storing (Know only parents but not children)
 Root puts a source route for each leaf and forwards

Transport/Communication protocols
WIFI
WiFi has the advantage of addressing a very wide variety of profiles because of the proliferation of its
family of standards. This means it will play a role in most IoT environments, alone or interworking
with more specialized protocols, or with cellular. Some IoT applications, such as vehicular services,
or video-based apps like connected security cameras, will need the bandwidth of the wireless
broadband network, implemented to enable other requirements like low latency (In critical
environments this may take place in a private network or slice).
WiFi is uniquely placed to support broadband and narrowband IoT applications from a common
platform that can work at varying levels of power consumption and signal range. The next release of
5G standards, Release 16, will prioritize IoT-focused capabilities such as latency below four
milliseconds and very high availability, to support emerging cases in the URLLC (ultra-reliable low
latency communications) category.

LiFi
To understand the capabilities of LiFi, or Light Fidelity, imagine a world where it’s possible to
connect to ultra-fast internet at the touch of a light switch. LiFi behaves like a wireless optical
networking technology that utilizes LEDs for data transmission. LiFi is essentially a lift-based form of
WiFi that uses light instead of radio waves to send information.
As we’ve already touched on, the way that LiFi reaches devices can be useful––especially in
environments where WiFi signals are weak or in areas that are susceptible to electromagnetic
interference––such as in hospitals or airplanes.
LiFi works by transmitting wireless internet connections at high speeds. The technology allows LED
light bulbs to transmit pulses of light that allows data to travel to and from receivers in a way that’s
undetectable to the human eye. Once a device’s receiver collects the information being transmitted,
it’s capable of interpreting the data in a way that’s similar to deciphering Morse code––only at a
significantly faster rate––millions of times per second. The potential transmission speeds for LiFi data
can surpass 100Gbps––faster than the fastest known form of WiFi, WiGig.

Bluetooth Low Energy (BLE)

 A wireless personal area network technology designed and aimed at novel applications in the
healthcare, fitness, beacons, security, and home entertainment industries.
 Compared to Classic Bluetooth, Bluetooth Low Energy is intended to provide considerably
reduced power consumption and cost while maintaining a similar communication range.
 Mobile operating systems including iOS, Android, Windows Phone and BlackBerry, as well as
macOS, Linux, Windows 8 and Windows 10, natively support Bluetooth Low Energy.
 Same specifications as Bluetooth 4.0

BLE - Features
 The lowest power consumption.
 Cost efficient and compatible.
 Robustness, security, and reliability.
 Connection range – upto 300 meters

BLE - Application
 Mesh profiles - Bluetooth mesh profiles use Bluetooth Low Energy to communicate with other
Bluetooth Low Energy devices in the network.
 Health care profiles – Monitoring devices.
 Sports and fitness profiles – fitness bands.
 Industrial monitoring sensors.
 Geography-based, targeted promotions.
 Public transportation apps.
NFC

NFC has its origins in radio frequency identification (RFID) technology, which uses electromagnetic
fields to encode and read information. Any NFC-enabled device has a small chip that is activated
when it comes in close proximity to another NFC chip (10 centimeters or less). NFC therefore enables
simple and safe two-way interactions between electronic devices.
There are two types of NFC devices: active and passive. Active NFC devices, such as smartphones,
are capable of both sending and receiving information. Passive NFC devices can transmit information
when read by active devices, but cannot read information themselves.
Consumers can use NFC technology for a variety of purposes:
 Performing contactless transactions
 Connecting electronic devices with a single tap
 Sharing business cards
 Accessing information from a smart poster
 Downloading digital content
 Providing credentials for security systems
The benefits of NFC include easy connections, rapid transactions, and simple exchange of data. NFC
serves as a complement to other popular wireless technologies such as Bluetooth, which has a wider
range than NFC but which also consumes more power.
Mobile wallets such as Apple Pay and Android Pay are the most visible use case of NFC technology.
According to a 2017 survey, 17 percent of U.S. consumers regularly use their smartphone to pay for
transactions, with adoption over 50 percent in some emerging economies such as India and Thailand.
However, the potential applications of NFC go far beyond mobile wallets. In June 2017, Apple
unlocked the iPhone’s NFC chip capabilities for uses other than Apple Pay, and Android devices have
long had NFC access as well. With more than 2 billion NFC-enabled devices (and counting), use of
the technology is expected to grow rapidly in the near future.
How NFC Works with IoT
The Internet of Things (IoT) is a massive network of billions of devices, from industrial sensors to
self-driving cars, that are connected to the Internet in order to collect and exchange information. Tech
market research company Juniper Research projects that by 2020, there will be 38.5 billion IoT-
connected gadgets.
By enabling closer integration and communication between devices, the IoT is widely expected to
shake up the ways that people live, work, and play. However, there are a few serious roadblocks that
stand on the path to mainstream IoT adoption.
For example, how do IoT objects know what a user is intending to do? How can you develop IoT
devices that are secure from external attacks? How can you connect unpowered objects to the IoT?
NFC solves many of the challenges associated with IoT:
With a straightforward tap-and-go mechanism, NFC makes it simple and intuitive to connect two
different IoT devices.
Because NFC chips must be in close proximity of each other to initiate a transaction, NFC is a clear
sign that the user intends to take a certain action. The short range of NFC also protects against
unauthorized access by hackers.
NFC includes built-in features such as encryption that cut down on the potential for eavesdropping
and other malicious activities.
Even objects without power or an IoT connection can passively exchange data via NFC tags. Users
with an NFC-enabled device can tap the gadget to get information such as URLs.
For example, NFC technology can be used as a substitute for hotel key cards. By downloading your
hotel reservation to a mobile app, the NFC chip in your smartphone becomes a key that can unlock
your door. In addition, NFC technology can be integrated almost anywhere you might need cheap,
battery-less electronic tags like in event tickets and animal tags for wildlife or livestock tracking.
Another major NFC use case for IoT is home automation. For example, introducing a new device onto
your “smart home” network can be a laborious process that involves long passwords and complicated
configurations.
You can skip this process by equipping your home with an NFC-enabled IoT “gateway” that serves as
the nexus for all IoT applications. When you introduce a new device with an NFC tag, you can simply
tap the device against the gateway to automatically connect it to your home network.
A second challenge for building a unified smart home is the use of different communications
technologies, such as Wi-Fi and Bluetooth. NFC tags can bridge the gap between these technologies
with a single tap, letting you do away with the time-consuming process of device discovery and
pairing
Data protocols-(MQTT, CoAP, XMP)
Meet the Extensible Messaging and Presence Protocol (XMPP):
Instant messaging (IM) is a popular application among casual Internet users as well as business users.
It provides not only the means for users to communicate with others in real time, but also get their
presence information (available, away from the computer, offline, and so on). One of the earliest open
IM protocols was Jabber, which began as a nonstandard IM protocol in 1998 (developed by Jeremie
Miller). As an extensible protocol built with XML, Jabber quickly found other applications as a
general transport or message-oriented middleware (MoM). Eventually, XMPP arose from Jabber as a
standards-based protocol in the form of an IETF working group protocol document: RFC 3920,
"Extensible Messaging and Presence Protocol (XMPP)."
XMPP is not alone as a general-purpose messaging transport. Other popular protocols such as XML-
RPC and SOAP can provide this capability with function call-like semantics. Newer methods such as
Representational State Transfer (ReST) provide managed file access using URLs to specify the
location, object, and method.
XMPP architecture
XMPP has similarities to other application-layer protocols like SMTP. In these architectures, a client
with a unique name communicates with another client with a unique name through an associated
server. Each client implements the client form of the protocol, where the server provides routing
capability. Figure 1 illustrates this simple architecture. In this case, each client is part of the same
domain (discovery.nasa.guv).
Figure 1. A simple XMPP architecture, consisting of a server and two clients

Servers can also communicate for purposes of routing between domains (for example, between
discovery.nasa.guv and europa.nasa.guv). Further, gateways can exist for purposes of translating
between foreign messaging domains and protocols. The example in Figure 2 shows an XMPP network
with gateways to a Short Message Service (SMS) domain and an SMTP domain. Gateways are most
often used in this context to translate between IM protocols (for example, XMPP to Internet Relay
Chat [IRC]). As an extensible protocol, XMPP is an ideal backbone protocol to provide universal
connectivity among different endpoint protocols. The XMPP gateway permits the termination of a
given client-to-server session and the initiation of a new session to the target endpoint protocol (along
with the necessary protocol translation).
Figure 2. A more complex XMPP architecture, including XMPP gateways

Addresses in XMPP
Addresses (or Jabber IDs [JIDs]) in XMPP are similar to standard e-mail addresses with a couple of
notable differences. JIDs include an optional node, a domain, and an optional resource in the form:
[ node "@" ] domain [ "/" resource ]
Show more
The most common use is defining an IM user (like an e-mail address), such as
[email protected]. 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 ([email protected]/terminal) and another JID (session) from an EVA pod
([email protected]/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.
The XMPP protocol
XMPP is a relatively simple protocol that occurs over TCP sockets using XML messages.
Asynchronous communication occurs within XML streams and with XML stanzas. An XML stream is
an envelope that encapsulates the exchange of XML information between two entities. XML streams
communicate XML stanzas, which are discrete units of information. For example, XML stanzas are
used within XMPP to communicate messages (text between IM users) as well as presence
information. To illustrate these concepts, look at a simple example of an IM communication using
XMPP between two clients.
Figure 3 illustrates a simple conversation between two entities. Note that at least one server appears
within the conversation (in this case, because both clients exist within the same domain, there's
exactly one server). In Figure 3, the left client is known as the initiating entity (it initiates the XMPP
communication between the two entities). This XML stream uses the to attribute to identify the
receiving domain (as well as define the XML namespace). The receiving client on the right receives
this XML stream and responds with an XML stream response (in this case, using the from attribute).
At this stage, a number of different negotiations are possible, such as authentication and encryption.
Ignore this aspect for this discussion (in addition to server-to-server communication when IM clients
appear in separate domains).
Figure 3. Sample (simplified) XMPP communication
A cases study with MQTT/CoAP usage