IPv6 and IoT Protocols for Connected Devices

Internet of Things (ETUA31202)(TY ETC SEM-I)
Unit IV : IP based Protocols for IOT

Dr. Pravin G. Gawande
pravin.gawande@viit.ac.in,
Department of Electronics and Telecommunication Engineering
BRACT’S, Vishwakarma Institute of Information Technology, Pune-48

(An Autonomous Institute affiliated to Savitribai Phule Pune University)
(NBA and NAAC accredited, ISO 9001:2015 certified)
Teaching Scheme
Text books or Reference Any other information
Topics Unit IV : IP based Protocols for IOT
books or Datasheets
1 IPv6 (Internet Protocol version 6),
2 6LoWPAN (IPv6 over Low-Power Wireless Personal Area Networks),
3 RPL(Routing Protocol),
4 REST (REpresentational State Transfer),
5 AMQP (Advanced Message Queuing Protocol),
6 CoAP (Constrained application protocol),
7 MQTT (Message Queue Telemetry Transport),
8 Authorization and Access Control in IOT
Objective: To Learn different protocols used for IoT design
Course Outcomes: Demonstrate various IP based protocols for IoT systems
Department of Electronics and Telecommunication Engineering, VIIT, Pune-48 2

Teaching Scheme
Text Books
Sr. No. Title Authors Publication
ISBN : 978-1- 84821-140-
T1 1. The Internet of Things Connecting Objects to the Web Hakima Chaouchi
7, Wiley Publications
Olivier Hersent, David
T2 2. The Internet of Things: Key Applications and Protocols WileyPublications
Boswarthick, and Omar Elloumi
Reference Books
Arsheep Bahga and Vijay
R1 Internet of Things, Universities Press
Madisetti
Building the Internet of Things with IPv6 and MIPv6: The ISBN: 978-1-118-47347-
R2 Daniel Minoli
Evolving World of M2M Communications 4, Willy Publications
The Internet of Things: Enabling Technologies, Platforms, and Pethuru Raj and Anupama C.
R3 CRC Press
Use Cases Raman
Authorization and Access Control Foundations, Frameworks, Parikshit N. Mahalle, Shashikant
R4 CRC Press
and Applications S. Bhong, Gitanjali R. Shinde
Online
O1 https://onlinecourses.nptel.ac.in/noc17_cs22/course NPTEL course
O2 http://www.cse.wustl.edu/~jain/cse570-15/ftp/ iot_prot/ index.html

Protocol Architecture of IoT
Introduction
• Internet protocols are the set of rules which are use in addressing the packets of data so that they can travel
across networks to arrive at the correct destination.
• Internet protocol facilitates the exchange of data between two different computers.
• Data to be transfer through the internet is divide up into small pieces refer to packets.
• Each packet is recognize by IP information which also helps the routers send the packets to the right place.
• Internet protocol is very useful and crucial also because the entire web service is running on these internet
protocols.
• These protocols are the medium between two different systems to connect with each other.
• Without these protocols, using the internet to transfer data between two devices is not possible.

NETWORK LAYER PROTOCOLS

NETWORK LAYER PROTOCOLS
• Network layer: This layer is responsible for routing of
data in the network. This layer ensures that data or
packet from a source device is delivered to the correct
destination device. The devices are identified using
their IP address, which is assigned by using the
Internet protocol (IP). In 6LoWPAN, IPv6, or RPL, is
used in the network layer.
• IPv4
• Exhausted in 2011
• 32 bit address
• IPv6
• 128 bit addresses
• 6LoWPAN
• Limited processing capability
• Shows compression mechanism with IPv6 over
802.15.4

The First Major Protocol
• In the 1970s, the first major internet protocol was invented. This protocol was ipv4(internet protocol version 4).
This protocol was originally design to use as an isolated military network. After its successful use in the military
area, it was then adapted for public use as well. The address of ipv4 was 32 bit because in the 1970s, 32-bit was
the biggest register find in any common processors. But there were a large number of limitations in the ipv4.
These limitations were:-
• There were a large number of devices that were connect up to the internet throughout the world due to which there was a
lack of address spaces and the size of the address space was exhausting.
• Due to the insufficient size of the ipv4, it was not accommodating additional parameters which were leading to weak
protocol extensibility.
• Security was one of the major limitations of ipv4. There was no limit to the information hosted on the network.
• Service support for ipv4 was also very poor. There was no information regarding the bandwidth placement and delays need
for the smooth operation of the network were also not support by.
• 50% of all addresses were reserved for the united states of america because that was the place where the internet was born.
• Due to the increase in the number of servers connected to the internet, the number of ipv4 routers also increased. These ipv4
routers started consuming A great amount of memory and resources on internet routers.
Due To The Above-Listed Limitations, It Was Clear That A Day Will Come When IPv4 Address Space Will Run Out. IPv4 Will Not
Last Forever. Hence To Overcome The Limitations, A Better And New Version Of Internet Protocol IPv6 (Internet Protocol Version 6)
Was Build.

What Is IPv6 In IoT?
• Before going on IPv6, there might be A question in your mind that if IPv6 in IOT is the
updated version of IPv4, then where is IPv5?
• Well, the answer to your question is that the Internet Engineering Task Force(IETF) who
build IPv4 decide to skip IPv5 as it will also eventually run out of addresses. Hence they
decided to directly jump on IPv6 where there will be nothing to worry about running out of
IP addresses again.
• IPv6 is the most latest version of the internet protocol. Devices that use the internet are
recognized by their own IP addresses so that internet communication can work. IPv6 in IOT
identifies these devices so that they can be located through the internet easily.

• IPv4
• IPv4 has 32-bit addressing which is able to support about 4.5 billion devices.
• But because of the large number of laptops, computers, smartphones, and the internet of
things devices, it was proved that more addresses are required for the devices.
• IPv6 was created in 1998 which uses 128-bit addressing. It supports approximately 350
trillion trillion devices. The addressing method of IPv6 includes eight groups of four
hexadecimal digits, while the IPv4 addresses used to have four sets of one to three digits
numbers.

• Internet Protocol version 6 (IPv6) is the latest revision of the Internet Protocol (IP) and the
first version of the protocol to be widely deployed.
• IPv6 was developed by the Internet Engineering Task Force (IETF) to deal with the long-
anticipated problem of IPv4 address exhaustion.
• Internet Protocol version 6 is a new addressing protocol designed to incorporate all the
possible requirements of future Internet known to us as Internet version 2.
• This protocol as its predecessor IPv4, works on the Network Layer (Layer-3).
• Along with its offering of an enormous amount of logical address space, this protocol has
ample features which address the shortcoming of IPv4.
https://www.tutorialspoint.com/ipv6/ipv6_overview.htm

Why the New IP Version?

• So far, IPv4 has proven itself as a robust routable addressing protocol and has served us for
decades on its best effort-delivery mechanism.
• It was designed in the early 80s and did not get any major change afterward. At the time of
its birth, the Internet was limited only to a few universities for their research and to the
Department of Defense.
• IPv4 is 32 bits long and offers around 4,294,967,296 (232) addresses. This address space
was considered more than enough at that time.

Why the New IP Version?

Given below are the major points that played a key role in the birth of IPv6:
• Internet has grown exponentially and the address space allowed by IPv4 is saturating. There is a
requirement to have a protocol that can satisfy the needs of future Internet addresses that is
expected to grow in an unexpected manner.
• IPv4 on its own does not provide any security feature. Data has to be encrypted with some other
security application before being sent on the Internet.
• Data prioritization in IPv4 is not up to date. Though IPv4 has a few bits reserved for Type of
Service or Quality of Service, but they do not provide much functionality.
• IPv4 enabled clients can be configured manually or they need some address configuration
mechanism. It does not have a mechanism to configure a device to have globally unique IP
address.

Why Not IPv5? Here is a table of IP versions and how they are used:
• Till date, Internet Protocol has been recognized has
IPv4 only.
• Version 0 to 3 were used while the protocol was itself
under development and experimental process.
• So, we can assume lots of background activities
remain active before putting a protocol into
production.
• Similarly, protocol version 5 was used while
experimenting with the stream protocol for Internet.
• It is known to us as Internet Stream Protocol which
used Internet Protocol number 5 to encapsulate its
datagram. It was never brought into public use, but it
was already used.

Brief History
After IPv4’s development in the early 80s, the available IPv4 address pool begun to shrink rapidly as
the demand of addresses exponentially increased with Internet. Taking pre-cognizance of the situation
that might arise, IETF, in 1994, initiated the development of an addressing protocol to replace IPv4.
The progress of IPv6 can be tracked by means of the RFC published:
• 1998 – RFC 2460 – Basic Protocol
• 2003 – RFC 2553 – Basic Socket API
• 2003 – RFC 3315 – DHCPv6
• 2004 – RFC 3775 – Mobile IPv6
• 2004 – RFC 3697 – Flow Label Specification
• 2006 – RFC 4291 – Address architecture (revision)
• 2006 – RFC 4294 – Node requirement
On June 06, 2012, some of the Internet giants chose to put their Servers on IPv6. Presently they are
using Dual Stack mechanism to implement IPv6 parallel in with IPv4.

The successor of IPv4 is not designed to be backward compatible. Trying to keep the basic
functionalities of IP addressing, IPv6 is redesigned entirely. It offers the following features:
• Larger Address Space
• Simplified Header
• End-to-end Connectivity
• Auto-configuration
• Faster Forwarding/Routing
• IPSec
• No Broadcast
• Anycast Support
• Mobility
• Enhanced Priority Support
• Smooth Transition
• Extensibility

• Larger Address Space: In contrast to IPv4, IPv6 uses 4 times more bits to address a device on the
Internet. This much of extra bits can provide approximately 3.4×1038 different combinations of
addresses. This address can accumulate the aggressive requirement of address allotment for almost
everything in this world. According to an estimate, 1564 addresses can be allocated to every square
meter of this earth.
• Simplified Header: IPv6’s header has been simplified by moving all unnecessary information and
options (which are present in IPv4 header) to the end of the IPv6 header. IPv6 header is only twice
as bigger than IPv4 provided the fact that IPv6 address is four times longer.
• End-to-end Connectivity: Every system now has unique IP address and can traverse through the
Internet without using NAT or other translating components. After IPv6 is fully implemented,
every host can directly reach other hosts on the Internet, with some limitations involved like
Firewall, organization policies, etc.

• Auto-configuration: IPv6 supports both stateful and stateless auto configuration mode of its host
devices. This way, absence of a DHCP server does not put a halt on inter segment communication.
• Faster Forwarding/Routing: Simplified header puts all unnecessary information at the end of the
header. The information contained in the first part of the header is adequate for a Router to take
routing decisions, thus making routing decision as quickly as looking at the mandatory header.
• IPSec: Initially it was decided that IPv6 must have IPSec security, making it more secure than
IPv4. This feature has now been made optional.
• No Broadcast: Though Ethernet/Token Ring are considered as broadcast network because they
support Broadcasting, IPv6 does not have any broadcast support any more. It uses multicast to
communicate with multiple hosts.

• Anycast Support: This is another characteristic of IPv6. IPv6 has introduced Anycast mode of
packet routing. In this mode, multiple interfaces over the Internet are assigned same Anycast IP
address. Routers, while routing, send the packet to the nearest destination.
• Mobility: IPv6 was designed keeping mobility in mind. This feature enables hosts (such as mobile
phone) to roam around in different geographical area and remain connected with the same IP
address. The mobility feature of IPv6 takes advantage of auto IP configuration and Extension
headers.
• Enhanced Priority Support: IPv4 used 6 bits DSCP (Differential Service Code Point) and 2 bits
ECN (Explicit Congestion Notification) to provide Quality of Service but it could only be used if
the end-to-end devices support it, that is, the source and destination device and underlying network
must support it. In IPv6, Traffic class and Flow label are used to tell the underlying routers how to
efficiently process the packet and route it.

• Smooth Transition: Large IP address scheme in IPv6 enables to allocate devices with globally
unique IP addresses. This mechanism saves IP addresses and NAT is not required. So devices can
send/receive data among each other, for example, VoIP and/or any streaming media can be used
much efficiently. Other fact is, the header is less loaded, so routers can take forwarding decisions
and forward them as quickly as they arrive.
• Extensibility: One of the major advantages of IPv6 header is that it is extensible to add more
information in the option part. IPv4 provides only 40-bytes for options, whereas options in IPv6
can be as much as the size of IPv6 packet itself.

In computer networking, addressing mode refers to the mechanism of hosting an address on the
network. IPv6 offers several types of modes by which a single host can be addressed. More than one
host can be addressed at once or the host at the closest distance can be addressed.
Unicast
In unicast mode of addressing, an IPv6 interface
(host) is uniquely identified in a network
segment. The IPv6 packet contains both source
and destination IP addresses. A host interface is
equipped with an IP address which is unique in
that network segment.When a network switch or
a router receives a unicast IP packet, destined to
a single host, it sends out one of its outgoing
interface which connects to that particular host.

Multicast
The IPv6 multicast mode is same as that of IPv4.
The packet destined to multiple hosts is sent on
a special multicast address. All the hosts
interested in that multicast information, need to
join that multicast group first. All the interfaces
that joined the group receive the multicast
packet and process it, while other hosts not
interested in multicast packets ignore the
multicast information.

Anycast
IPv6 has introduced a new type of addressing,
which is called Anycast addressing. In this
addressing mode, multiple interfaces (hosts) are
assigned same Anycast IP address. When a host
wishes to communicate with a host equipped
with an Anycast IP address, it sends a Unicast
message. With the help of complex routing
mechanism, that Unicast message is delivered to
the host closest to the Sender in terms of
Routing cost.

Advantages Of IPv6 In The Internet Of Things
• IoT is A vast field of technology. This field includes A large number of devices and their working is mainly focused via
the internet. IPv6 is capable of giving out various IP addresses to these IoT devices so that they can be easily
recognized on the internet and can work efficiently to transfer data from one IoT device to another.
• IPv6 networks have auto-configuration capabilities which are quite simple and can be managed easily in larger
installations. With the help of this feature of IPv6, configuration effort and deployment cost in the field of IoT reduces
drastically.
• IPv6 is capable of sending large data packets simultaneously to conserve bandwidth. With the help of fast transmission
of data due to ipv6 in IoT, devices used in IoT will also be able to interact with each other.
• IPv6 provides far better security than ipv4. It provides confidentiality, authenticity, and data integrity as well. This
security given by IPv6 is of utmost importance to IoT because of its high dependency on network.
• IPv6 in IoT has a highly efficient multicast communication feature that eliminates the requirement for routine
broadcast messaging. This improvement helps in preserving the battery life of IoT devices by reducing the number of
packets processed.
• IPv6 provides multiple addresses to devices. Its routing mechanism is also distributed in A better way than ipv4. With
the help of this feature, programmers will have the liberty to assign IoT end-device addresses that are consistent with
their own applications and network practices.

IP Next Generation Protocol
IPv6
Greatly expanded More attractive for
address space future Internet applications
128
(2 ) compared to IPv4
Potential socio-economic
benefits for
Multi Access:
ubiquity of the Internet ;
Enhanced life
China’s Next Generation Internet – 2008 Olympics
mobility

IPv6 Deployment: Vital to Bridging the Digital Divide
Internet is now a critical global infrastructure for socio-economic development and growing faster in
developing countries :
It is necessary to take account of the needs of developing countries
Developing Countries have shown significant improvement in ICT but still lag behind in Internet access
Mobile/Wireless growing at a much faster rate than fixed networks
Relatively greater availability of mobile/wireless networks in many developing and emerging economies
Internet access using mobile networks: Lower Cost, Higher speed of deployment than fixed networks
Digital Divide may be reduced by extending mobile networks

IPv6 Deployment: Essential for wireless Internet
Emergence of mobiles as platform for wireless Internet access especially in developing countries will
put more pressure on the IP address space
Require a larger IP address space to enable wireless networking & mobility

IPv6 protocol provides the availability & extensibility of IP addresses :
Large-scale sensor networks, IP Security, Mobile IPv6, IP-based Multimedia
IPv6 is emerging as the preferred platform and is a core component of the wireless Internet architecture (3G &
Beyond 3G)
Need for fair and equitable policies for the management/allocation on IPv6
Current & future challenges of wireless Internet require IPv6

IPv6 address
An Internet Protocol Version 6 address (IPv6 address) is a numeric label that is used to identify and locate a network
interface of a computer or a network node participating in a computer network using IPv6. IP addresses are included in
the packet header to indicate the source and the destination of each packet. The IP address of the destination is used to
make decisions about routing IP packets to other networks.
https://en.wikipedia.org/wiki/IPv6_address

IPv6 address
The upper 64 bits are used for

The lower 64 bits identify the address
routing. of the interface or node, and is derive
d from the actual physical or MAC
address using IEEE’s Extended Uni
que Identifier (EUI-64) format.
If we look at the upper 64 bits in more detail we can see that it is split
into 2 blocks of 48 and 16 bits respectively the lower 16 bits are use
d for subnets on an internal networks, and are controlled by a
network administrator.
The upper 48 bits are used for the global network addresses and
are for routing over the internet.
http://www.steves-internet-guide.com/ipv6-guide/

IPv6 address Types and Scope
IPv6 addresses have three types:
• Global Unicast Address –Scope Internet- routed on Internet
• Unique Local — Scope Internal Network or VPN internally routable, but Not routed on Internet
• Link Local – Scope network link- Not Routed internally or externally.

Global Unicast Address
This address type is equivalent to IPv4’s public address. Global Unicast addresses in IPv6 are globally identifiable and
uniquely addressable.
Global Routing Prefix: The most significant 48-bits are designated as Global Routing Prefix which is assigned to
specific autonomous system. The three most significant bits of Global Routing Prefix is always set to 001.

Link-Local Address
Auto-configured IPv6 address is known as Link-Local address. This address always starts with FE80. The first 16 bits
of link-local address is always set to 1111 1110 1000 0000 (FE80). The next 48-bits are set to 0, thus:
Link-local addresses are used for communication among IPv6 hosts on a link (broadcast segment) only. These addresses
are not routable, so a Router never forwards these addresses outside the link.

Unique-Local Address
This type of IPv6 address is globally unique, but it should be used in local communication. The second half of this
address contain Interface ID and the first half is divided among Prefix, Local Bit, Global ID and Subnet ID.
Prefix is always set to 1111 110. L bit, is set to 1 if the address is locally assigned. So far, the meaning of L bit to 0 is not
defined. Therefore, Unique Local IPv6 address always starts with ‘FD’.

Scope of IPv6 Unicast Addresses:
• The scope of Link-local address is limited to

the segment.
• Unique Local Address are locally global,
but are not routed over the Internet, limiting
their scope to an organization’s boundary.
• Global Unicast addresses are globally
unique and recognizable.
• They shall make the essence of Internet v2
addressing.

Version 6 has slightly complex structure of IP address than that of IPv4. IPv6 has reserved a few addresses and address
notations for special purposes. See the table below:
• As shown in the table, the address 0:0:0:0:0:0:0:0/128 does not specify anything and is said to be an unspecified
address. After simplifying, all the 0s are compacted to ::/128.
• In IPv4, the address 0.0.0.0 with netmask 0.0.0.0 represents the default route. The same concept is also applied to
IPv6, address 0:0:0:0:0:0:0:0 with netmask all 0s represents the default route. After applying IPv6 rule, this address
is compressed to ::/0.
• Loopback addresses in IPv4 are represented by 127.0.0.1 to 127.255.255.255 series. But in IPv6, only
0:0:0:0:0:0:0:1/128 represents the Loopback address. After loopback address, it can be represented as ::1/128.
Reserved Multicast Address for Routing Protocols
• Table shows the reserved multicast addresses
used by interior routing protocol.
• The addresses are reserved following the same
rules of IPv4.
Reserved Multicast Address for Routers/Node

• These addresses help routers and hosts to speak
to available routers and hosts on a segment
without being configured with an IPv6 address.
Hosts use EUI-64 based auto-configuration to
self-configure an IPv6 address and then speak to
available hosts/routers on the segment by means
of these addresses.
Fixed Header
• The wonder of IPv6 lies in its header.

• An IPv6 address is 4 times larger than
IPv4, but surprisingly, the header of an
IPv6 address is only 2 times larger than
that of IPv4.
• IPv6 headers have one Fixed Header and
zero or more Optional (Extension)
Headers.
• All the necessary information that is
essential for a router is kept in the Fixed
Header.
• The Extension Header contains optional
information that helps routers to
http://www.steves-internet-guide.com/ipv6-guide/ understand how to handle a packet/flow.

Version (4-bits): It represents the version of
Fixed Header Internet Protocol, i.e. 0110.
Traffic Class (8-bits): These 8 bits are divided
into two parts. The most significant 6 bits are
used for Type of Service to let the Router
Known what services should be provided to
this packet. The least significant 2 bits are used
for Explicit Congestion Notification (ECN).
Flow Label (20-bits): This label is used to
maintain the sequential flow of the packets
belonging to a communication. The source
labels the sequence to help the router identify
that a particular packet belongs to a specific
flow of information. This field helps avoid re-
ordering of data packets. It is designed for
http://www.steves-internet-guide.com/ipv6-guide/ streaming/real-time media.

Payload Length (16-bits): This field is used to
Fixed Header tell the routers how much information a
particular packet contains in its payload.
Payload is composed of Extension Headers and
Upper Layer data. With 16 bits, up to 65535
bytes can be indicated; but if the Extension
Headers contain Hop-by-Hop Extension
Header, then the payload may exceed 65535
bytes and this field is set to 0.
Next Header (8-bits): This field is used to
indicate either the type of Extension Header, or
if the Extension Header is not present then it
indicates the Upper Layer PDU. The values for
the type of Upper Layer PDU are same as
IPv4’s.

Hop Limit (8-bits): This field is used to stop
Fixed Header packet to loop in the network infinitely. This is
same as TTL in IPv4. The value of Hop Limit
field is decremented by 1 as it passes a link
(router/hop). When the field reaches 0 the
packet is discarded.
Source Address (128-bits): This field indicates
the address of originator of the packet.
Destination Address (128-bits): This field
provides the address of intended recipient of
the packet.

6LoWPAN (IPv6 over Low-Power Wireless Personal Area Networks)
• 6LoWPAN stands for IPv6 over Low-Power Wireless Personal Area Networks.
• It is an open standard defined in RFC 6282 by the Internet engineering task force (IETF).
• The key feature of 6LoWPAN that makes it suitable for IoT communication is that though it was originally designed
to support IEEE 802.15.4 low-power wireless networks in the 2.4-GHz band, it now supports a wide range of
networking media such as sub-1 GHz low-power RF, Bluetooth smart, power line control (PLC), and low-power
Wi-Fi
Pethuru Raj and Anupama C. Raman - The Internet of Things. Enabling Technologies, Platforms, and Use Cases (2017, CRC Press)
6LoWPAN
• Network Architecture of 6LoWPAN
• The architecture of 6LoWPAN mesh network is
depicted in the diagram that is given in Figure.
• The uplink to the Internet is provided by the
access point (AP), which in this case is an IPv6
router.
• Different types of devices such as PCs and
servers could be connected to the AP.
• The components of the 6LoWPAN network are
connected to the IPv6 network using a
6LoWPAN edge router.
6LoWPAN

• Following are the functions performed by the
edge route
❑ It enables exchange of data between
6LoWPAN devices and the Internet (or other
IPv6 network).
❑ It enables exchange of data among devices that
are part of 6LoWPAN network.
❑ It helps to generate and maintain the 6LoWPAN
network
6LoWPAN

• As 6LoWPAN networks can communicate
natively with IP networks, they are connected to
IP networks simply using IP routers.
• In general, 6LoWPAN networks will typically
act as stub networks as they always operate on
the edge.
6LoWPAN

• The edge routers that are used to connect
6LoWPAN networks to other IP networks
forward IP datagrams between different media
that are used in IP networks.
• The media used in IP network could be Ethernet,
Wi-Fi, 3G, or 4G. As the edge routers used in
the 6LoWPAN network forward datagrams to
other IP networks using network layer, they do
not maintain the state of application layer.
• This in turn lowers the workload on the edge
router in terms of processing power, which
makes it possible to use low cost embedded
devices with simple software as edge routers.
6LoWPAN

• The devices that are present in a 6LoWPAN
network can be classified into two categories:
• ◾ Routers
• ◾ Hosts
• Routers are devices that route data to other
nodes in the 6LoWPAN network.
• Hosts are also known as end point devices, and
they do not have the capability to route data to
other devices in the network.
• Host could also be a sleepy device that could
check the routers at regular intervals for data
6LoWPAN
• Protocol Stack of 6LoWPAN

• The protocol stack of 6LoWPAN is
shown in Figure.
• Many protocols such as ZigBee require
complex application layer gateway in
order to connect to the Internet.
• 6LoWPAN solves this issue with the help
of an adaptation layer that is present in
between the IP stack’s data link and
network layer.
• The adaptation layer allows transmission
of IPv6 datagrams over IEEE 802.15.4.
6LoWPAN
• Protocol Stack of 6LoWPAN
Now let us compare the features of OSI
layer protocol stack to 6LoWPAN protocol
stack.
• Physical layer:
• This layer in the OSI model is
responsible for the conversion of data
bits into signal that can be transmitted
through air.
• In 6LoWPAN, IEEE 802.15.4 is used as
physical layer.
6LoWPAN
• Data link layer:
• This layer ensures that a reliable
connection or link is established between
two nodes by correcting the errors that
occur in physical layer during data
transmission.
• The media access control (MAC) layer
that provides access to the media is also
present in the data link layer.
• In 6LoWPAN, IEEE 802.15.4 is the
MAC layer.
• The adaptation layer of 6LoWPAN that
provides adaptation from IPv6 to IEEE
802.15.4 is also present in the data link
layer.
6LoWPAN
• Network layer:
• This layer is responsible for routing of
data in the network.
• This layer ensures that data or packet
from a source device is delivered to the
correct destination device.
• The devices are identified using their IP
address, which is assigned by using the
Internet protocol (IP).
• In 6LoWPAN, IPv6, or RPL, is used in
the network layer.
6LoWPAN
• Transport layer:
• The transport layer helps ensure that multiple
applications running on each device have their
own communication channel and can start
sessions between applications running on other
end devices.
• Transmission control protocol (TCP) is the
prominent transport layer protocol used in the
Internet.
• However, as TCP is a connection oriented
protocol, it incurs significant overhead and may
not be suitable for all devices especially for
devices that have low power consumption.
• In sucscenarios, user datagram protocol (UDP)
which is a connectionless protocol with a lower
overhead could be a better choice.
6LoWPAN
• Application layer:
• The main responsibility of application layer
is data formatting.
• A popular application layer that is used in
the Internet is HTTP that runs over TCP.
• HTTP uses XML that in turn is a text-based
language with a large overhead.
• Hence, it is not suitable for 6LoWPAN
systems that have low power consumption.
• As HTTP is not suitable for use in
6LoWPAN systems, several other
alternatives like COAP and MQTT are used
in 6LoWPAN systems.
6LoWPAN
• In short, 6LoWPAN is very promising for

use in the IoT market because of the
following reasons:
◾ Support for IP communication
◾ Support for large mesh network topology
◾ Very low power consumption
◾ Robust communication capabilities
RPL-Routing Protocol
• RPL stands for routing protocol for low

power and lossy networks.
• It is an IPv6 protocol.
• Lowpower lossy networks include wireless
personal area networks (WPANs), low-
power line communication (PLC) networks,
and wireless sensor networks (WSNs).
• These networks have some characteristics:
❑ Capability to optimize and save energy

❑ Capability to support traffic patterns other
than unicast communication
❑ Capability to run routing protocols over
link layers with restricted frame sizes
• RPL was designed to support minimal routing needs by building a highly
robust topology over lossy networks.
• This protocol provides support for various types of traffic models:
multipoint-to-point, point-to-multipoint, and point-to-point.
• Devices in the network that use this protocol are connected to each other in
such a way that no cycles are present in the connection.
• In order to achieve this, a node called destination oriented directed acyclic
graph (DODAG), which is routed at a single destination, is built initially.
• RPL specifications refer to DODAG as DODAG root. Each node that is a
part of DODAG knows its parent node but does not have any information
about its child nodes.
• RPL maintains at least a single path from each node to the root and the
preferred parent.
• This is done in order to increase performance by pursuing a faster path.
• The DODAG topology used in RPL is depicted in Figure.
• The four important types of control

messages are used by RPL to maintain
routing topology and maintain the
updated routing information. These
control messages are summarized in
Table.
REST (representational state transfer)
• REST (REpresentational State Transfer) is an architectural style for developing web services. REST is
popular due to its simplicity and the fact that it builds upon existing systems and features of the internet's
Hypertext Transfer Protocol (HTTP) in order to achieve its objectives, as opposed to creating new
standards, frameworks and technologies.
" REST " was coined by Roy Fielding in his Ph.D. dissertation [1] to describe a design pattern for implementing
networked systems. [http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm]
Motivation for REST The motivation for developing REST was to create a design pattern for how the Web should work,
such that it could serve as the guiding framework for the Web standards and designing Web services.
"Representational State Transfer is intended to evoke an image of how a well-designed Web application behaves: a
network of web pages (a virtual state-machine), where the user progresses through an application by selecting links (state
transitions), resulting in the next page (representing the next state of the application) being transferred to the user and
rendered for their use." - Roy Fielding
https://www.techtarget.com/searchapparchitecture/definition/REST-REpresentational-State-Transfer
REST - Not a Standard

• REST is not a standard
• You will not see the W3C putting out a REST specification.
• You will not see IBM or Microsoft or Sun selling a REST developer's toolkit.
• REST is just a design pattern
• You can't bottle up a pattern.
• You can only understand it and design your Web services to it.
• REST does prescribe the use of standards:
• HTTP
• URL
• XML/HTML/GIF/JPEG/etc.(Resource Representations)
• text/xml, text/html, image/gif, image/jpeg, etc. (Resource Types, MIME Types)

• Why is it called "Representational State Transfer? "

• The Client references a Webresource using a URL.
• A representation of the resource is returned (in this case as an HTML document).
• The representation (e.g., Boeing747.html) places the client in a new state.
• When the client selects a hyperlink in Boeing747.html, it accesses another resource.
• The new representation places the client application into yet another state. Thus, the client application transfers state
with each resource representation.
Resource Client http://www.boeing.com/aircraft/747 Fuel requirements Maintenance schedule ... Boeing747.html
• Today everything is fitted with one or more APIs in order to connect and collaborate with everything else in the vicinity
or with remote ones over any network.
• With the overwhelming success of APIs, these days APIs are penetrative and pervasive.
• Especially for the impending connected era, the rise and relevance of APIs are grandiosely significant.
• We have embedded, mobile, web, cloud, analytical, and enterprise applications and services in plenty, and all are fitted
with apt APIs for enabling seamless and spontaneous integration and interactions.
• REST (representational state transfer), being synonymous with XML or JSON over HTTP, is the one standout for the
forthcoming IoT (Han 2014; Cubo 2014) days. In the recent past, JSON has supplanted XML as the data format of
choice for the web.
• At its core, REST is an architectural pattern for uniformly accessing and modifying a resource. One entity (the server) is the authority over
the current state of an object.
• Other entities may request a representation of the current object and may also send requests to create, modify, or delete the object.
• The current popular REST model uses URIs to identify objects (/lamp/1234), HTTP verbs to specify an action, and JSON to represent the
object. To fetch an object, a client may send an HTTP request to GET /lamp/1234. The server may respond with an HTTP 200 and a body
containing JSON data.
• REST services can be developed and described using the web application description language (WADL).
• WADL is based on XML and describes applications based on HTTP.
• It supports the automatic description of RESTful services with machine-processable service descriptions.
• The SA-REST is an open, flexible, and standards-based approach for adding semantics to RESTful services.
• In the context of IoT, the RESTful services have many distinct advantages over arbitrary web services (i.e., SOAP) such
as less overhead, low parsing-complexity, statelessness, and tighter integration with HTTP.
• In addition, applications supporting RESTful services perform better on wireless sensor network with limited resources.
• There are a few integrated frameworks to speed up the process of building and deploying a bevy of RESTful services
across industry verticals.
There are several advantages to using REST. They are as follows:

• Resource-based. A primary benefit of using REST, from both a client and server perspective, is that REST interactions
are based on constructs which are familiar to anyone accustomed to using HTTP. Employing a resource-based approach,
REST defines how developers interact with web services.
• Communication. REST-based interactions communicate their status through numerical HTTP status codes. REST APIs
use these HTTP status codes to detect errors and ease the API monitoring process. They include the following:
• 404 error indicates that a requested resource wasn't found;
• 401 status response code is triggered by an unauthorized request;
• 200 status response code indicates that a request was successful; and
• 500 error signals an unrecoverable application fault on the server.
• Familiarity. Most developers are already familiar with key elements of the REST architecture, such as Secure Sockets Layer
(SSL) encryption and Transport Layer Security (TLS).
There are several advantages to using REST. They are as follows:

• Language-independent. When creating RESTful APIs or web services, developers can employ any language that uses
HTTP to make web-based requests. This capability makes it easy for programmers to choose the technologies they
prefer to work with and that best suit their needs.
• Pervasive. The popularity of REST is due to its widespread use in both server- and client-side implementations. For
example, on the server side, developers can employ REST-based frameworks, including Restlet and Apache CXF. On
the client side, developers can employ a variety of frameworks (i.e., jQuery, Node.js, Angular, EmberJS, etc.) and
invoke RESTful web services using standard libraries built into their APIs.
• Web APIs. When it comes to caching, RESTful services employ effective HTTP mechanisms. For example, by
providing many endpoints, a REST API makes it easier for developers to create complex queries that can meet specific
deployment needs.
Disadvantages of REST are as follows:
• Architecture. Developers working with REST frequently encounter limitations due to its architecture design. These
include multiplexing multiple requests over a single TCP connection, having different resource requests for each resource
file, server request uploads, and long HTTP request headers, which cause delays in webpage loading.
• Stateless applications. Since HTTP does not store state-based information between request-response cycles, the client
must perform state management tasks. This makes it difficult for programmers to implement server updates without the
use of client-side polling or other types of webhooks that send data and executable commands from one app to another.
• Definition. Developers generally disagree over defining REST-based designs. As an architectural style, REST lacks a
clear reference implementation or a definitive standard that designates whether a specific design can be defined as
RESTful. This also leads to uncertainty over whether a given web API conforms to REST-based principles.
• Data overfetching/underfetching. RESTful services frequently return large amounts of unusable data combined with
relevant information, typically the result of multiple server queries. These inefficiencies also increase the time it takes for
a client to return all the required data.
Semantics of HTTP methods
The following table shows how HTTP methods are intended to be used in HTTP APIs, including RESTful ones.
Semantics of HTTP methods

HTTP method Description
GET Get a representation of the target resource’s state.
POST Let the target resource process the representation enclosed in the request.
Create or replace the state of the target resource with the state defined by the representation
PUT
enclosed in the request.
PATCH Partially update resource’s state.
DELETE Delete the target resource’s state.
OPTIONS Advertising the available methods.
https://en.wikipedia.org/wiki/Representational_state_transfer
JSON and XML REST data formats

• JSON is the data exchange format for the RESTful interaction. The two most common data exchange formats are
JSON and XML, and many RESTful web services can use both formats interchangeably, as long as the client can
request the interaction to happen in either format.
• Note that while JSON and XML are popular data exchange formats, REST itself does not put any restrictions on what
the format should be. In fact, some RESTful web services exchange binary data for the sake of efficiency. This is
another benefit to working with REST-based web services, as the software architect is given a great deal of freedom in
terms of how best to implement a service.
REST and the IoT

• Given the near ubiquity of REST APIs and the explosive number of devices on the internet of things (IoT), it seems to be a perfect
pairing. Compact formats based on JSON, EXI and CBOR (Concise Binary Object Representation), a JSON offshoot, are used and
RESTful APIs are likewise compact.
• In an IoT scheme, devices work in a client-server relationship. In that relationship, devices can act as clients, servers or both. Devices can
act as a client and initiate contact with a directory, such as the CoRE Resource Directory, or another device. Devices can also act in the
capacity of an origin server or resource, such as to serve as a sensor, serving temperatures or other status indicators.
• Yet, as noted above, all client-server operations using REST should be stateless, and any state management that is required should happen
on the client, not the server. That means all messages must contain all the information to process it, independent from previous messages.
• Two things have helped REST become popular with IoT developers. First, REST is already pervasive, well-understood and replicable.
Second, because the data requested from resources in IoT tends to be simple, such as a sensor's current reading, and static, such as a
manufacturer's device description, REST, which utilizes the internet's HTTP, is a natural fit.
AMQP (Advanced Message Queuing Protocol)
• The Advanced Message Queuing Protocol (AMQP) is an open standard application layer protocol for message-
oriented middleware.
• The defining features of AMQP are message orientation, queuing, routing (including point-to-point and publish-and-
subscribe), reliability and security.
• Advanced message queuing protocol (AMQP) was designed as an open replacement for existing proprietary
messaging middleware (http://www.amqp.org/).
• Two of the most important reasons to use AMQP are reliability and interoperability.
• As the name implies, it provides a wide range of features related to messaging, including reliable queuing, topic-
based publish-and-subscribe messaging, flexible routing, transactions, and security.
• AMQP exchanges route messages directly by topic and also based on headers.
• AMQP is a binary wire protocol, which was designed for interoperability between different vendors.
• Where other protocols have failed, AMQP adoption has been strong.
• Companies like :
• JP Morgan use it to process one billion messages a day.
• NASA uses it for Nebula cloud computing.
• Google uses it for complex event processing.
• Here are a couple of additional AMQP examples and links:

1. It is used in one of the world’s largest biometric databases India’s Aadhar project—home to 1.2 billion identities.
2. It is used in the ocean observatories initiative—an architecture that collects 8 terabytes of data per day.
• AMQP is all about queues.

• It sends transactional messages between servers. As a message-centric middleware that arose from the banking
industry, it can process thousands of reliable queued transactions.
• AMQP (Figure) is focused on not losing messages.

• Any communications from the publishers to exchanges
and from queues to subscribers use TCP, which provides
strictly reliable P2P connection.
• Further, endpoints must acknowledge the acceptance of
each message.
• The standard also describes an optional transaction
mode with a formal multiphase commit sequence.
• True to its origins in the banking industry, AMQP
middleware focuses on tracking all messages and
ensuring each is delivered as intended, regardless of
failures or reboots.
Internal and external interactions through AMQP.
• robomq.io (Figure) is an AMQP message

broker connecting devices, systems, clouds,
and things to create smart and context-aware
applications. It provides cloud-hosted
message queue as a service platform bundled
with a management interface, dashboards,
analytics, and software development kit
(SDK).
• It is a highly scalable message queue cluster
with built-in redundancy, failover, and elastic
scaling to add resources as the message traffic The robomq’s queuing solution for device interactions.
increases
• robomq.io brings the messaging platform in a
fully managed and hosted message queue as a
service SaaS model offering reliability, scale,
and manageability required by today’s cloud,
mobile, M2M, and IoT applications. robomq.io
is an end-to-end IoT middleware platform that
can connect any device to any system,
application, or cloud through its suite of
connectors and adapters.
• It has an IoT gateway that allows devices and
device mesh networks to connect to the cloud
over cellular or wired connectivity.
• This also comes with real-time analytics engine, The robomq’s queuing solution for device interactions.
data-driven alerts, and device diagnostics and
management capabilities to help you manage Pethuru Raj and Anupama C. Raman - The Internet of Things. Enabling
your IoT ecosystem effectively. Technologies, Platforms, and Use Cases (2017, CRC Press)

• RabbitMQ is an open source message broker.
• It receives and delivers messages from and to your applications.
• A message broker is (unlike databases and key-value store) purpose built to highly effectively and safely deliver
information between your applications.
The end-to-end steps of cloud AMQP.

• CloudAMQP (Figure) is a hosted and managed RabbitMQ service in the cloud. Hosted message queues let you
pass messages between processes and other systems. Messages are published to a queue by a producer. Then
consumers can then get the messages off the queue when the consumers want to handle the messages. In-between, it
can route, buffer, and persist the messages according to rules you give it. Messages can be sent across languages,
platforms, and OS. This way of handling messages decouples your processes and creates a highly scalable system.
The end-to-end steps of cloud AMQP.

• AMQP Frame Types
• Nine AMQP frame types are defined that are used to initiate, control and tear down the transfer of messages between
two peers:
1. Open (connection open)
2. Begin (session open)
3. Attach (initiate new link)
4. Transfer (for sending actual messages)
5. Flow (controls message flow rate)
6. Disposition (Informs the changes in state of transfer)
7. Detach (terminate the link)
8. End (session close)
9. Close (connection close)
• AMQP Communications
• All the AMQP concepts—from connection, session, and link to performatives and messages—fit together to define
how the communication happens between two peers. The main steps involved are:
• Open/Close a connection (respectively after opening a network connection and before closing it) using “open” and
“close” performatives.
• Begin/End a session inside the connection thanks to “begin” and “end” performatives.
• Attach/Detach a link inside the session using “attach” and “detach” performatives.
• Send/Receive messages with flow control thanks to “transfer”, “disposition”, and “flow” performatives.
https://dzone.com/refcardz/amqp-essentials
• Communication: Open
• In order to open the communication with a peer, first
there is an AMQP/SASL handshake on the raw TCP
connection, then the AMQP “open” performative is
exchanged to define the max frame size (flow control),
maximum number of channels, and so on.
• Inside the connection, a session is started using the
“begin” performative specifying the window size
(number of frames for flow control).
• Finally, the “attach” performative is used to attach a
link.
• Communication: Send
• After the link is attached, the receiver can send a “flow”
performative to the sender specifying the credit number
to limit number of messages it’s able to receive (flow
control).
• The producer sends data using the “transfer”
performative, which is followed by a “disposition”
performative by the receiver if and only if the required
QoS is at level one (at least once) and the messages are
not settled by the producer.
• The receiver can send only one “disposition”
performative to confirm that it has received more
“transfer” performatives.
• Communication: Receive
• A receive communication is the opposite flow of a send.
The receiver sends the “flow” performative to set the
credit-based flow control and how many messages it can
receive before processing them.
• For one or more “transfers”, it replies with a
“disposition” if the QoS level is greater than zero and
the producer requires settlement.
• Communication: Close
• Closing a communication means it becomes detached
from all active links using the “detach” performative.
After that, the “end” performative is used to end the
session, and the “close” performative is used to close the
connection.
• Of course, the last step is to close the underlying
network connection at the socket level.
• Applications
• Connecting different systems and processes to talk to each other.
• Allowing servers to respond to immediate requests quickly and delegate(dealing) time consuming tasks for later
processing.
• Distributing a message to multiple recipients for consumption.
• Enabling offline clients to fetch data at a later time.
• Increasing reliability and uptime of application deployments(increasing speed of the applications).

CoAP (Constrained application protocol)
• Constrained application protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and
constrained networks in the IoT space.
• The protocol is designed for M2M applications such as smart energy and building automation.
• CoAP includes several HTTP functionalities, which have been redesigned for M2M applications over constrained
environments on the IoT.
• That is, it takes into account the low processing power and energy constraints of small embedded devices, such as
sensors.
• In addition, CoAP offers a number of features that HTTP lacks such as built-in resource discovery, IP multicast
support, native push model, and asynchronous message exchange.
• There are many implementations of CoAP in various languages, such as libcoap1 (an open-source C-implementation)
and Sensinode’s NanoService2.
• The comparison of HTTP and CoAP stacks is pictorially

indicated in Figure.
• Physical layer and data link layer:

• Wireless networks are essential for the IoT.
• The IEEE 802.15.4 standard specifies the physical layer
(PHY) and media access control (MAC) for low-rate
wireless personal networks (LR-WPANs), which focuses
on low-power consumption, low-cost, and low-rate data
communication between constrained devices.

• Network layer:
• IPv6 over Low-Power Wireless Personal Area Networks
(6LoWPAN) standard defined by the IETF brings the IP
to small embedded devices (e.g., sensors) in even the
most constrained networks such as IEEE 802.15.4.
• In addition to 6LoWPAN, the IETF routing over low
power and lossy networks (ROLL) working group has
defined IPv6 routing protocol for low-power and lossy
networks (RPL) for smart object Internetworking.
• Together these networking technologies provide means
for small embedded devices to integrate into the Internet.

• Transport layer:
• HTTP typically relies on TCP, which has performance
problems over low-power and lossy networks (LLNs), is
sensitive to mobility, does not provide multicast support,
and has high overhead for short-lived transactions.
• CoAP, on the other hand, is built on top of the user
datagram protocol (UDP), which provides significantly
lower overhead and supports multicast.
• Application layer:
• CoAP provides RESTful services optimized for resource-
constrained networks and devices, and thus makes the
protocol suitable to the IoT and M2M applications.
• In addition, it provides reliability (with default timeout
and exponential back-off retransmission) mechanisms
even without the use of TCP as the transport layer.
• One of the most important design goals of CoAP has also
been to keep the message overhead as small as possible.
HTTP can also be used over 6LoWPAN. However, the
results show that the power consumption and bytes
transferred per transaction are drastically lower when
using CoAP over 6LoWPAN compared to HTTP over
6LoWPAN, and thus increasing the battery lifetime of
constrained devices.
• Payload:
• The W3C efficient XML interchange (EXI) format is a
very compact, high-performance XML representation,
which significantly reduces bandwidth requirements
without compromising the efficient use of other
resources, such as battery life, code size, processing
power, and memory.
• As said before, CoAP is an IoT protocol.
• CoAP stands for Constrained Application Protocol, and it is defined in RFC7252.
• CoAP is a simple protocol with low overhead specifically designed for constrained devices (such as
microcontrollers) and constrained networks.
• This protocol is used in M2M data exchange and is very similar to HTTP, even if there are important differences that
we will cover laters.
The main features of CoAP protocols are:
• Web protocol used in M2M with constrained requirements
• Asynchronous message exchange
• Low overhead and very simple to parse
• URI and content-type support
• Proxy and caching capabilities
As you may notice, some features are very similar to HTTP even if CoAP must not be considered a compressed HTTP protocol
because CoAP is specifically designed for IoT and in more details for M2M so it is very optimized for this task.
https://dzone.com/articles/coap-protocol-step-by-step-guide
• From the abstraction protocol layer, CoAP can be represented as:
• There are two different layers that make CoAp protocol:

• Messages and Request/Response.
• The Messages layer deals with UDP and with asynchronous
messages.
• The Request/Response layer manages request/response
interaction based on request/response messages.
Before going deeper into the CoAp protocol, structure is

• CoAP supports four different message
useful to define some terms that we will use later:
types:
• Endpoint: An entity that participates in the CoAP
• Confirmable
protocol. Usually, an Endpoint is identified with a host
• Non-confirmable
• Sender: The entity that sends a message
• Acknowledgment
• Recipient: The destination of a message
• Reset
• Client: The entity that sends a request and the destination
of the response
• Server: The entity that receives a request from a client
and sends back a response to the client
• CoAP Messages Model: Confirmable message
• A confirmable message is a reliable message.

• When exchanging messages between two endpoints,
these messages can be reliable.
• In CoAP, a reliable message is obtained using a
Confirmable message (CON).
• Using this kind of message, the client can be sure that
the message will arrive at the server.
• A Confirmable message is sent again and again until
the other party sends an acknowledge message
(ACK).
• The ACK message contains the same ID of the
confirmable message (CON).
• CoAP Messages Model: Confirmable message
If the server has troubles managing the incoming request,

it can send back a Rest message (RST) instead of the
Acknowledge message (ACK):
• CoAP Messages Model: Non-Confirmable message
• The other message category is the Non-confirmable

(NON) messages.
• These are messages that don’t require an
Acknowledge by the server.
• They are unreliable messages or in other words
messages that do not contain critical information that
must be delivered to the server.
• To this category belongs messages that contain values
read from sensors.
• CoAP Request/Response Model
• The CoAP Request/Response is the second layer in

the CoAP abstraction layer. The request is sent using
a Confirmable (CON) or Non-Confirmable (NON)
message. There are several scenarios depending on if
the server can answer immediately to the client
request or the answer if not available.
• If the server can answer immediately to the client

request, then if the request is carried using a
Confirmable message (CON), the server sends back
to the client an Acknowledge message containing the
response or the error code:
• CoAP Request/Response Model
• As you can notice in the CoAP message, there is a

Token. The Token is different from the Message-ID
and it is used to match the request and the response.
• If the server can’t answer to the request coming from

the client immediately, then it sends an Acknowledge
message with an empty response. As soon as the
response is available, then the server sends a new
Confirmable message to the client containing the
response. At this point, the client sends back an
Acknowledge message:
MQTT (Message Queue Telemetry Transport )
• Message Queue Telemetry Transport

(MQTT) was introduced by IBM in 1999
and standardized by OASIS in 2013
• It is designed to provide embedded
connectivity between applications and
middleware’s on one side and networks and
communications on the other side.
• MQTT: A protocol for collecting device
data and communicating it to servers (D2S)
• Characteristics of MQTT
• The MQTT has some unique features which are hardly found in other protocols. Some of the features of an
MQTT are given below:
• It is a machine to machine protocol, i.e., it provides communication between the devices.

• It is designed as a simple and lightweight messaging protocol that uses a publish/subscribe system to exchange the
information between the client and the server.
• It does not require that both the client and the server establish a connection at the same time.
• It provides faster data transmission, like how WhatsApp/messenger provides a faster delivery. It's a real-time
messaging protocol.
• It allows the clients to subscribe to the narrow selection of topics so that they can receive the information they are
looking for.
https://www.javatpoint.com/mqtt-protocol
MQTT Architecture
• To understand the MQTT architecture, we first

look at the components of the MQTT.
1. Message
2. Client
3. Server or Broker
4. TOPIC
1. Message
• The message is the data that is carried out by
the protocol across the network for the
application.
• When the message is transmitted over the
network, then the message contains the
following parameters:
• Payload data
• Quality of Service (QoS)
• Collection of Properties
• Topic Name
2. Client
• In MQTT, the subscriber and publisher are the
two roles of a client. The clients subscribe to
the topics to publish and receive messages.
In MQTT, the client performs two operations:
• Publish: When the client sends the data to the

server, then we call this operation as a publish.
• Subscribe: When the client receives the data
from the server, then we call this operation a
subscription.
3. Server
• The device or a program that allows the client
to publish the messages and subscribe to the
messages.
• A server accepts the network connection from
the client, accepts the messages from the client,
processes the subscribe and unsubscribe
requests, forwards the application messages to
the client, and closes the network connection
from the client.
4. TOPIC
The label provided to the message is checked against the subscription known by the server is known as TOPIC.
• Now we will look at the architecture of MQTT.
• To understand it more clearly, we will look at the example.
• Suppose a device has a temperature sensor and wants to send the
rating to the server or the broker.
• If the phone or desktop application wishes to receive this
temperature value on the other side, then there will be two things
that happened.
• The publisher first defines the topic; for example, the temperature
then publishes the message, i.e., the temperature's value.
• After publishing the message, the phone or the desktop
application on the other side will subscribe to the topic, i.e.,
temperature and then receive the published message, i.e., the
value of the temperature. The server or the broker's role is to
deliver the published message to the phone or the desktop
application.
• MQTT Message Format

• The MQTT uses the command and the command acknowledgment format, which means that each command has an
associated acknowledgment.
• As shown in the figure that the connect command has connect acknowledgment, subscribe command has subscribe
acknowledgment, and publish command has publish acknowledgment.
• This mechanism is similar to the handshaking mechanism as in TCP protocol.
• The MQTT message format consists of 2 bytes fixed header, which is present in all the MQTT packets.
• The second field is a variable header, which is not always present.
• The third field is a payload, which is also not always present.
• The payload field basically contains the data which is being sent.
• We might think that the payload is a compulsory field, but it does not happen.
• Some commands do not use the payload field, for example, disconnect message.
• As we can observe in the above format that the fixed header contains two bytes. The first byte contains the following
fields:
• MQTT Control Packet Type: It occupies 4 bits, i.e., 7 to 4-bit positions. This 4-bit is an assigned value, and each
bit represents the MQTT control packet type.
• Flag specific to each MQTT packet type: The remaining 4-bits represent flag specific to each MQTT packet type.
• The byte 2 contains the remaining length, which is a variable-length byte integer. It represents the number of bytes
remaining in a current control packet, including data in the variable header and payload.
• MQTT Control Packet Types
• The table shows the control packet types

with 4-bit value and direction flow.
• As we can observe that every command is
followed by acknowledgment like
CONNECT has CONNACK,
• PUBLISH has PUBACK, PUBREC,
PUBREL, and PUBCOMP, SUBSCRIBE
has SUBACK,
• UNSUBSCRIBE has UNSUBACK.
• MQTT Control Packet Types
• The table shows the control packet types

with 4-bit value and direction flow.
• As we can observe that every command is
followed by acknowledgment like
CONNECT has CONNACK,
• PUBLISH has PUBACK, PUBREC,
PUBREL, and PUBCOMP, SUBSCRIBE
has SUBACK,
• UNSUBSCRIBE has UNSUBACK.
What are the benefits of using MQTT?

The lightweight properties and minimum overhead of the MQTT protocol architecture help ensure smooth data transfer
with low bandwidth and reduce the load on the CPU and RAM. Among MQTT's advantages over competing protocols
are the following:
• efficient data transmission and quick to implement, due to its being a lightweight protocol;
• low network usage, due to minimized data packets;
• efficient distribution of data;
• successful implementation of remote sensing and control;
• fast, efficient message delivery;
• uses small amounts of power, which is good for the connected devices; and
• optimizes network bandwidth.
What are the drawbacks of MQTT?

Potential downsides to MQTT include the following:
• MQTT has slower transmit cycles compared to Constrained Application Protocol (CoAP).
• MQTT's resource discovery works on flexible topic subscription, whereas CoAP uses a stable resource
discovery system.
• MQTT is unencrypted. Instead, it uses TLS/SSL (Transport Layer Security/Secure Sockets Layer) for security
encryption.
• It is difficult to create a globally scalable MQTT network.
• Other MQTT challenges relate to security, interoperability and authentication.
How is MQTT used in IoT?

• Because MQTT clients are small, they require minimal resources and thus can be used on small microcontrollers,
according to MQTT.org. To optimize network bandwidth, MQTT headers are small.
• Plus, MQTT "can scale to connect with millions of IoT devices," according to the organization.
• As a result, MQTT is one of the most commonly used protocols in IoT and IIoT infrastructure -- for example, for
utilities industries to efficiently transmit data between their services and their customers and devices.
Examples of MQTT use in IoT infrastructure include the following:
• Smart metering. The MQTT protocol can be used to transmit data with guaranteed message delivery to provide
accurate meter readings in real-time. This helps make billing more accurate.
• Gathering ambient sensor data. Sensors used in remote environments are often low-power devices, so MQTT is
a good fit for IoT sensor buildouts with lower-priority data transmission needs.
• Machine health data. Ably, which provides a pub/sub messaging platform, gives the example of a wind turbine
requiring "guaranteed delivery of machine health data to local teams even before that information hits a data
center."
• Billing systems. MQTT helps eliminate duplicate or lost message packets in billing or invoicing.
Whether used for smart metering, fast outage response or other IoT and IIoT applications, MQTT enables resource-
constrained IoT devices to send, or publish, information about a specific topic to a server that acts as an MQTT message
broker. The broker then pushes the information out to those clients that have subscribed previously to the topic.
To a human, a topic looks like a hierarchical file path. Clients can subscribe to a specific level of a topic's hierarchy or use a
wildcard character to subscribe to multiple levels. The client could be an IoT sensor in the field or an application in a data
center that processes IoT data.

• MQTT runs on top of TCP/IP using a PUSH/

SUBSCRIBE topology.
• In MQTT architecture, there are two types of systems:
clients and brokers.
• A broker is the server that the clients communicate with.
• The broker receives communications from clients and
sends those communications on to other clients.
• Clients do not communicate directly with each other, but
rather connect to the broker.
• Each client may be either a publisher, a subscriber, or
both.
MQTT is an event-driven protocol. There is no periodic or ongoing data transmission. This keeps transmission to a
minimum. A client only publishes when there is information to be sent, and a broker only sends out information to
subscribers when new data arrives.

• Another way MQTT minimizes its transmissions is with a

tightly defined, small message construction.
• Each message has a fixed header of just 2 bytes.
• An optional header may be used but increases the size of
the message.
• The message payload is limited to just 256 MB.
• Three different Quality of Service (QoS) levels allow
network designers to choose between minimizing data
transmission and maximizing reliability.

• QoS 0 – Offers the minimum amount of data

transmission.
• With this level, each message is delivered to a subscriber
once with no confirmation.
• There is no way to know if subscribers received the
message.
• This method is sometimes referred to as “fire and forget”
or as “at most once delivery.”
• Because this level assumes that delivery is complete,
messages are not stored for delivery to disconnected
clients that later reconnect.

• QoS 1 – The broker attempts to deliver the message and

then waits for a confirmation response from the
subscriber.
• If a confirmation is not received within a specified time
frame, the message is sent again.
• Using this method, the subscriber may receive the
message more than once if the broker does not receive the
subscriber’s acknowledgment in time.
• This is sometimes referred to as “at least once delivery”.
• QoS 2 – The client and broker use a four-step handshake

to ensure that the message is received, and that it is
received only once.
• This is sometimes referred to as “exactly once delivery”.

• Applications of MQTT
• Facebook Messenger uses MQTT for online chat.
• Amazon Web Services use Amazon IoT with MQTT.
• Microsoft Azure IoT Hub uses MQTT as its main
protocol for telemetry messages.
• The EVRYTHNG IoT platform uses MQTT as an M2M
protocol for millions of connected products.
• Adafruit launched a free MQTT cloud service for IoT
experimenters called Adafruit IO.

SMQTT (Secure Message Queue Telemetry Transport )
• SMQTT is Secure MQTT.

• SMQTT is proposed only to enhance MQTT security features.

Difference between COAP and MQTT protocols
COAP MQTT
COAP stands for Constrained Application Protocol. MQTT stands for Message query telemetry transport.
For communication, it uses a request-response prototype. For communication, it uses the publish-subscribe prototype.
It uses asynchronous and synchronous messaging. It uses only asynchronous mode for messaging.
It uses User Datagram Protocol (UDP). It uses the Transmission Control Protocol (TCP).
The Heather size of CAOP is 4 bytes. The Heather size of MQTT is 2 bytes.
It is RESTful based. It is not RESTful based.

It does not have persistence support. It is mainly used for live communication and has persistence support.
It will give labels to the messages. It does not have any such function.
It has a secured system, and its usability is in Utility area It is very secure, and its usability is in IoT applications.
networks.
It has Low Latency and NAT issues. It has Low Latency and NAT issues.
https://www.tutorialspoint.com/difference-between-coap-and-mqtt-protocols
Difference between COAP and MQTT protocols
Basis of COAP MQTT
Abbreviation Constrained Application Protocol Message Queuing Telemetry Transport
Communication Type It uses Request-Response model. It uses Publish-Subscribe model
Messaging Mode This uses both Asynchronous and Synchronous. This uses only Asynchronous
Transport layer protocol This mainly uses User Datagram protocol(UDP) This mainly uses Transmission Control protocol(TCP)
Header size It has 4 bytes sized header It has 2 bytes sized header
RESTful based Yes it uses REST principles No it does not uses REST principles
Persistence support It does not has such support It supports and best used for live data communication
Message Labelling It provides by adding labels to the messages. It has no such feature.
Usability/Security It is used in Utility area networks and has secured mechanism. It is used in IoT applications and is secure
Effectiveness Effectiveness in LNN is excellent. Effectiveness in LNN is low.
Communication Model Communication model is one-one. Communication model is many-many.
https://www.geeksforgeeks.org/difference-between-coap-and-mqtt-protocols/
Authorization and Access Control in IOT
Traditional access control framework in Distributed IoT

• Security of data and devices is one of the most significant concerns in the IoT.
• For example, security breaches and unwanted alterations in smart healthcare systems and faulty/irregular readings
of the health parameters of the patient could lead to unwanted or even fatal treatment.
• The whole credibility and deployability of the IoT solely depend on security aspects only.
• Authentication and access control are the first steps towards any security measures.
• With whom and up to what extent, one can access/communicate the devices in IoT scenario, are important aspects
of security, especially when diverse devices with different capability have to perform collaborative tasks.

• Authorization is a process which ensures that a specific user has rights to perform specific operations on a specific
object. This is generally by granting different types of permissions to different types of users based on their role in a
city government.
• For example, a fire station executive will just be able to read the data pertaining to other city departments like
water; he/she may not be able to edit it. Edit permissions may be given only to the city supervisors or executives
who belong to the water department of the city.
• The different types of permissions for different users on different objects are mapped and stored in a table, which is
called Access Control List (ACL).
• The different types of permissions, which are given for users, are classified as the following:
• Read only: The user has permission to only read the object. The user cannot delete or edit the object. These types of
permissions are granted to staff who are not required to perform any alteration on the data.
• Read and write: The user has permission to read and alter the object. These types of permissions are granted to
authorities who have the overall authority and discretion to validate the rights and access permissions of other users.


IPv6 and IoT Protocols for Connected Devices

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

IPv6 and IoT Protocols for Connected Devices

Uploaded by

Copyright:

Available Formats

Internet of Things (ETUA31202)(TY ETC SEM-I)

Unit IV : IP based Protocols for IOT

Department of Electronics and Telecommunication Engineering

BRACT’S, Vishwakarma Institute of Information Technology, Pune-48

Objective: To Learn different protocols used for IoT design

Course Outcomes: Demonstrate various IP based protocols for IoT systems

Department of Electronics and Telecommunication Engineering, VIIT, Pune-48 2

Department of Electronics and Telecommunication Engineering, VIIT, Pune-48 3

Department of Electronics and Telecommunication Engineering, VIIT, Pune-48 4

Department of Electronics and Telecommunication Engineering, VIIT, Pune-48 5

Department of Electronics and Telecommunication Engineering, VIIT, Pune-48 6

Department of Electronics and Telecommunication Engineering, VIIT, Pune-48 7

Department of Electronics and Telecommunication Engineering, VIIT, Pune-48 8

Department of Electronics and Telecommunication Engineering, VIIT, Pune-48 9

Department of Electronics and Telecommunication Engineering, VIIT, Pune-48 10

Why the New IP Version?

Department of Electronics and Telecommunication Engineering, VIIT, Pune-48 11

Why the New IP Version?

Department of Electronics and Telecommunication Engineering, VIIT, Pune-48 12

Department of Electronics and Telecommunication Engineering, VIIT, Pune-48 13

Department of Electronics and Telecommunication Engineering, VIIT, Pune-48 14

Department of Electronics and Telecommunication Engineering, VIIT, Pune-48 15

Department of Electronics and Telecommunication Engineering, VIIT, Pune-48 16

Department of Electronics and Telecommunication Engineering, VIIT, Pune-48 17

Department of Electronics and Telecommunication Engineering, VIIT, Pune-48 18

Department of Electronics and Telecommunication Engineering, VIIT, Pune-48 19

Department of Electronics and Telecommunication Engineering, VIIT, Pune-48 20

Department of Electronics and Telecommunication Engineering, VIIT, Pune-48 21

Department of Electronics and Telecommunication Engineering, VIIT, Pune-48 22

Department of Electronics and Telecommunication Engineering, VIIT, Pune-48 23

Department of Electronics and Telecommunication Engineering, VIIT, Pune-48 24

Mobile/Wireless growing at a much faster rate than fixed networks

Digital Divide may be reduced by extending mobile networks

Department of Electronics and Telecommunication Engineering, VIIT, Pune-48 25

Require a larger IP address space to enable wireless networking & mobility

Current & future challenges of wireless Internet require IPv6

Department of Electronics and Telecommunication Engineering, VIIT, Pune-48 26

Department of Electronics and Telecommunication Engineering, VIIT, Pune-48 27

The upper 64 bits are used for

Department of Electronics and Telecommunication Engineering, VIIT, Pune-48 28

Department of Electronics and Telecommunication Engineering, VIIT, Pune-48 29

Department of Electronics and Telecommunication Engineering, VIIT, Pune-48 30

Department of Electronics and Telecommunication Engineering, VIIT, Pune-48 31

Department of Electronics and Telecommunication Engineering, VIIT, Pune-48 32

Scope of IPv6 Unicast Addresses:

• The scope of Link-local address is limited to

Department of Electronics and Telecommunication Engineering, VIIT, Pune-48 33

Reserved Multicast Address for Routers/Node

• The wonder of IPv6 lies in its header.

Department of Electronics and Telecommunication Engineering, VIIT, Pune-48 36

Department of Electronics and Telecommunication Engineering, VIIT, Pune-48 37

Department of Electronics and Telecommunication Engineering, VIIT, Pune-48 38

Department of Electronics and Telecommunication Engineering, VIIT, Pune-48 39

• Network Architecture of 6LoWPAN

• Network Architecture of 6LoWPAN

• Network Architecture of 6LoWPAN

• Network Architecture of 6LoWPAN

• Protocol Stack of 6LoWPAN

• In short, 6LoWPAN is very promising for

• RPL stands for routing protocol for low

❑ Capability to optimize and save energy

• The four important types of control

REST - Not a Standard