16-02-2023

ZWAVE

Introduction to Internet of Things 53

6

536

INTRODUCTION

✓ Zwave (or Z wave or Z‐wave) is a protocol for communication

among devices used for home automation.
✓ It uses RF for signaling and control.
✓ Operating frequency is 908.42 MHz in the US & 868.42 MHz
in Europe.
✓ Mesh network topology is the main mode of operation, and
can support 232 nodes in a network.
Source: “What is Z‐Wave?”, Smart Home (Online)

Introduction to Internet of Things 53

7

537

1
 16-02-2023

ZWAVE GLOBAL OPERATING

FREQUENCY

Frequency in MHz Used in

865.2 India
868.1 Malaysia
868.42 ; 869.85 Europe
868.4 China, Korea
869.0 Russia
908.4 ; 916.0 USA
915.0 ‐ 926.0 Israel
919.8 Hong Kong
921.4 ; 919.8 Australia, New Zealand
922.0 ‐ 926.0 Japan
Source: “Z‐Wave”, Wikipedia (Online)

538

✓ Zwave utilizes GFSK modulation and Manchester channel

encoding.
✓ A central network controller device sets‐up and manages a
Zwave network.
✓ Each logical Zwave network has 1 Home (Network) ID and
multiple node IDs for the devices in it.
✓ Nodes with different Home IDs cannot communicate with
each other.
✓ Network ID length=4 Bytes, Node ID length=1 Byte.
Source: “What is Z‐Wave?”, Smart Home (Online)

Introduction to Internet of Things 53

9

539

2
 16-02-2023

GFSK

✓ Gaussian Frequency Shift Keying.

✓ Baseband pulses are passed through a Gaussian filter prior to
modulation.
✓ Filtering operation smoothens the pulses consisting of
streams of ‐1 and 1, and is known as Pulse shaping.
✓ Pulse shaping limits the modulated spectrum width.

Introduction to Internet of Things 54

0

540

Introduction to Internet of Things 54

1

541

3
 16-02-2023

✓ Uses source routed network mesh topology using 1 primary

controller.
✓ Devices communicate with one another when in range.
✓ When devices are not in range, messages are routed though
different nodes to bypass obstructions created by household
appliances or layout.
✓ This process of bypassing radio dead‐spots is done using a message
called Healing.
✓ As Zwave uses a source routed static network, mobile devices are
excluded from the network and only static devices are considered.
Source: “What is Z‐Wave?”, Smart Home (Online)

Introduction to Internet of Things 54

2

542

Introduction to Internet of Things 54

3

543

4
 16-02-2023

ZWAVE VS. ZIGBEE

Zwave Zigbee

✓ User friendly and provides a ✓ Requires so little power that

simple system that users can set devices can last up to seven years
up themselves. on one set of batteries.
✓ Ideal for someone with a basic ✓ Ideal for technology experts who
understanding of technology who want a system they can customize
wants to keep their home with their preferences and install
automation secure, efficient, themselves.
simple to use, and easy to
maintain.
Source: Sarah Brown, “ZigBee vs. Z‐Wave Review: What’s the Best Option for You?”, The SafeWise Report (Online), Mar 2016

Introduction to Internet of Things 54

4

544

ZWAVE VS. ZIGBEE

Zwave Zigbee

✓ Expensive. ✓ Cheaper than Zwave.

✓ Nine out of ten leading ✓ ZigBee Alliance consists of
security and communication nearly 400 member
companies in the U.S. use Z‐ organizations that use,
Wave in their smart home develop, and improve
solutions ZigBee’s open‐standard
wireless connection
Source: Sarah Brown, “ZigBee vs. Z‐Wave Review: What’s the Best Option for You?”, The SafeWise Report (Online), Mar 2016

Introduction to Internet of Things 54

5

545

5
 16-02-2023

NFC

Introduction to Internet of Things 54

6

546

INTRODUCTION

✓ Near field communication, or NFC for

short, is an offshoot of radio‐frequency Type B
identification (RFID).
✓ NFC is designed for use by devices within Type A FeliCa
close proximity to each other.
✓ All NFC types are similar but
communicate in slightly different ways. NFC
✓ FeliCa is commonly found in Japan.
Source: “How NFC Works”, NFC (Online)

Introduction to Internet of Things 54

7

547

6
 16-02-2023

NFC TYPES

✓ Passive devices contain information

which is readable by other devices,

Smartphone
however it cannot read information itself.
✓ NFC tags found in supermarket products Active Passive
are examples of passive NFC.
✓ Active devices are able to collect as well

NFC Tags
as transmit information.
✓ Smartphones are a good example of
active devices.
Source: “How NFC Works”, NFC (Online)

Introduction to Internet of Things 54

8

548

WORKING PRINCIPLE

✓ Works on the principle of magnetic induction.

✓ A reader emits a small electric current which creates a magnetic
field that in turn bridges the physical space between the devices.
✓ The generated field is received by a similar coil in the client device
where it is turned back into electrical impulses to communicate
data such as identification number status information or any other
information.
✓ ‘Passive’ NFC tags use the energy from the reader to encode their
response while ‘active’ or ‘peer‐to‐peer’ tags have their own power
source.
Source: “Inside NFC: how near field communication works”, APC (Online), Aug. 2011

Introduction to Internet of Things 54

9

549

7
 16-02-2023

Introduction to Internet of Things 55

0

550

NFC SPECIFICATIONS

✓ NFC's data‐transmission frequency is 13.56MHz.

✓ NFC can transmit data at a rate of either 106, 212 or 424 Kbps
(kilobits per second).
✓ Tags typically store between 96 and 512 bytes of data.
✓ Communication range is less than 20cms.

Source: “Inside NFC: how near field communication works”, APC (Online), Aug. 2011

Introduction to Internet of Things 55

1

551

8
 16-02-2023

MODES OF OPERATION

Peer‐to‐peer Lets two smartphones swap data

One active device picks up info from a

Read/Write passive one

NFC device can be used like a

Card emulation contactless credit card
Source: M. Egan, “What is NFC? Uses of NFC | How to use NFC on your smartphone”, TechAdvisor (Online), May 2015

Introduction to Internet of Things 55

2

552

NFC APPLICATIONS

✓ Smartphone based payments.

✓ Parcel tracking.
✓ Information tags in posters and advertisements.
✓ Computer game synchronized toys.
✓ Low‐power home automation systems.

Introduction to Internet of Things 55

3

553

9
 16-02-2023

6LOWPAN

Introduction to Internet of Things

5
5
4

554

INTRODUCTION

✓ Low‐power Wireless Personal Area Networks over IPv6.

✓ Allows for the smallest devices with limited processing ability
to transmit information wirelessly using an Internet protocol.
✓ Allows low‐power devices to connect to the Internet.
✓ Created by the Internet Engineering Task Force (IETF) ‐ RFC
5933 and RFC 4919.

Source: T. Winter, P.Thubert, A. Brandt, J. Hui, R. Kelsey, P.Levis, K. Pister, R. Struik , JP. Vasseur, R. Alexander,
“RPL: IPv6 Routing Protocol for Low‐Power and Lossy Networks”, IETF, Standards Track, Mar. 2012

Introduction to Internet of Things

5
5
5

555

10
 16-02-2023

FEATURES OF 6LOWPANS

✓ Allows IEEE 802.15.4 radios to carry 128‐bit addresses of

Internet Protocol version 6 (IPv6).
✓ Header compression and address translation techniques allow
the IEEE 802.15.4 radios to access the Internet.
✓ IPv6 packets compressed and reformatted to fit the IEEE
802.15.4 packet format.
✓ Uses include IoT, Smart grid, and M2M applications.

Introduction to Internet of Things

5
5
6

556

ADDRESSING IN
6LOWPAN

• 64‐bit addresses: globally

Addressing
unique
• 16 bit addresses: PAN specific;
64‐bit assigned by PAN coordinator
Extended • IPv6 multicast not supported by
802.15.4
16‐bit • IPv6 packets carried as link
Short layer broadcast frames

Introduction to Internet of Things

557

11
 16-02-2023

6LOWPAN PACKET FORMAT

1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
Length Flags DSN

IEEE 802.15.4
PAN ID
Destination (64 bit)

Source (64 bit)

Ver Traffic Class Flow Label

Payload Length Next Header Hop Limit

IPv6
Source Address (128 bit)

Destination Length (128 bit)

Introduction to Internet of Things

558

• The 6LoWPAN working group published several RFCs, but RFC 4994 is foundational
because it defines frame headers for the capabilities of header compression,
fragmentation, and mesh addressing.
• These headers can be stacked in the adaptation layer to keep these concepts separate
• while enforcing a structured method for expressing each capability.
• Depending on the implementation, all, none, or any combination of these capabilities and
their corresponding headers can be enabled.
• Figure shows some examples of typical 6LoWPAN header stacks.

559

12
 16-02-2023

(1) HEADER TYPE: DISPATCH

HEADER
1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8

0 1 Dispatch Type Specific Header

• Dispatch: Initiates communication

• 0,1: Identifier for Dispatch Type
• Dispatch:
• 6 bits
• Identifies the next header type
• Type Specific Header:
• Determined by Dispatch header

Introduction to Internet of Things

560

(2) HEADER TYPE: MESH ADDRESSING

HEADER

1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8

1 0 V F Hops Left Originator Address Final Address

• 1,0: ID for Mesh Addressing Header

• V: ‘0’ if originator is 64‐bit extended address, ‘1’ if 16‐bit
address
• F: ‘0’ if destination is 64‐bit addr., ‘1’ if 16‐bit addr.
• Hops Left: decremented by each node before sending to next
hop

Introduction to Internet of Things

561

13
 16-02-2023

• Fragmentation:
• The maximum transmission unit (MTU) for an IPv6 network must be at least 1280 bytes.
• The term MTU defines the size of the largest protocol data unit that can be passed.
• For IEEE 802.15.4, MTU is of 127 bytes.
• In IPv6, with a much larger MTU, is carried inside the 802.15.4 frame with a much smaller
one.
• To remedy this situation, large IPv6 packets must be fragmented across multiple 802.15.4
frames at Layer2.

562

• The fragment header utilized by 6LoWPAN is composed of three primary fields:

• Datagram Size, Datagram Tag, and Datagram Offset.
• The 1-byte Datagram Size field specifies the total size of the unfragmented payload.
• Datagram Tag identifies the set of fragments for a payload.
• Finally, the Datagram Offset field delineates how far into a payload a particular fragment
occurs.
• Figure provides an overview of a 6LoWPAN fragmentation header

563

14
 16-02-2023

(3) HEADER TYPE:

FRAGMENTATION HEADER

1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8

1 1 0 0 Datagram Size Datagram Tag

(a) First Fragment

1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8

1 1 0 0 Datagram Size Datagram Tag

Datagram Offset

(b) Subsequent Fragment

Introduction to Internet of Things

564

• In Figure, the 6LoWPAN fragmentation header field itself uses a unique bit value to
identify that the subsequent fields behind it are fragment fields as opposed to another
capability, such as header compression.
• Also, in the first fragment, the Datagram Offset field is not present because it would
simply be set to 0.
• This results in the first fragmentation header for an IPv6 payload being only 4 bytes long.
• The remainder of the fragments have a 5-byte header field so that the appropriate offset
can be specified

565

15
 16-02-2023

6LOWPAN ROUTING CONSIDERATIONS

✓ Mesh routing within

the PAN space.
✓ Routing between IPv6
and the PAN domain
✓ Routing protocols in
use:
▪ LOADng
▪ RPL

Introduction to Internet of Things 5

6
6

566

LOADNG ROUTING

✓ Derived from AODV and extended for use in IoT.

✓ Basic operations of LOADng include:
▪ Generation of Route Requests (RREQs) by a LOADng Router
(originator) for discovering a route to a destination,
▪ Forwarding of such RREQs until they reach the destination LOADng
Router,
▪ Generation of Route Replies (RREPs) upon receipt of an RREQ by the
indicated destination, and unicast hop‐by‐hop forwarding of these
RREPs towards the originator.
Source: Clausen, T.; Colin de Verdiere, A.; Yi, J.; Niktash, A.; Igarashi, Y.; Satoh, H.; Herberg, U.; Lavenu, C. et al. (January 2016). The
Lightweight On‐demand Ad hoc Distance‐vector Routing Protocol ‐ Next Generation (LOADng). IETF. I‐D draft‐clausen‐lln‐loadng‐14

Introduction to Internet of Things 5

6
7

567

16
 16-02-2023

▪ If a route is detected to be broken, a Route Error (RERR) message is

returned to the originator of that data packet to inform the originator
about the route breakage.
▪ Optimized flooding is supported, reducing the overhead incurred by
RREQ generation and flooding.
▪ Only the destination is permitted to respond to an RREQ.
▪ Intermediate LOADng Routers are explicitly prohibited from
responding to RREQs, even if they may have active routes to the
sought destination.
▪ RREQ/RREP messages generated by a given LOADng Router share a
single unique, monotonically increasing sequence number.
Source: Clausen, T.; Colin de Verdiere, A.; Yi, J.; Niktash, A.; Igarashi, Y.; Satoh, H.; Herberg, U.; Lavenu, C. et al. (January 2016). The
Lightweight On‐demand Ad hoc Distance‐vector Routing Protocol ‐ Next Generation (LOADng). IETF. I‐D draft‐clausen‐lln‐loadng‐14

Introduction to Internet of Things 5

6
8

568

RPL ROUTING

✓ Distance Vector IPv6 routing protocol for lossy and low power
networks.
✓ Maintains routing topology using low rate beaconing.
✓ Beaconing rate increases on detecting inconsistencies (e.g.
node/link in a route is down).
✓ Routing information included in the datagram itself.
✓ Proactive: Maintaining routing topology.
✓ Reactive: Resolving routing inconsistencies.
Source: T. Winter, P. Thubert, A. Brandt, J. Hui, R. Kelsey, P. Levis, K. Pister, R. Struik , JP. Vasseur, R. Alexander,
“RPL: IPv6 Routing Protocol for Low‐Power and Lossy Networks”, IETF, Standards Track, Mar. 2012

Introduction to Internet of Things 5

6
9

569

17
 16-02-2023

✓ RPL separates packet processing and forwarding from the

routing optimization objective, which helps in Low power
Lossy Networks (LLN).
✓ RPL supports message confidentiality and integrity.
✓ Supports Data‐Path Validation and Loop Detection
✓ Routing optimization objectives include
▪ minimizing energy
▪ minimizing latency
▪ satisfying constraints (w.r.t node power, bandwidth, etc.)
Source: T. Winter, P.Thubert, A. Brandt, J. Hui, R. Kelsey, P.Levis, K. Pister, R. Struik , JP. Vasseur, R. Alexander,
“RPL: IPv6 Routing Protocol for Low‐Power and Lossy Networks”, IETF, Standards Track, Mar. 2012

Introduction to Internet of Things 5

7
0

570

✓ RPL operations require bidirectional links.

✓ In some LLN scenarios, those links may exhibit asymmetric
properties.
✓ It is required that the reachability of a router be verified
before the router can be used as a parent.

Source: T. Winter, P.Thubert, A. Brandt, J. Hui, R. Kelsey, P.Levis, K. Pister, R. Struik , JP. Vasseur, R. Alexander,
“RPL: IPv6 Routing Protocol for Low‐Power and Lossy Networks”, IETF, Standards Track, Mar. 2012

Introduction to Internet of Things 5

7
1

571

18
 16-02-2023

FUNCTIONALITY-BASED IOT PROTOCOL

ORGANIZATION

✓ Connectivity (6LowPAN, RPL)

✓ Identification (EPC, uCode, IPv6, URIs)
✓ Communication / Transport (WiFi, Bluetooth, LPWAN)
✓ Discovery (Physical Web, mDNS, DNS‐SD)
✓ Data Protocols (MQTT, CoAP, AMQP, Websocket, Node)
✓ Device Management (TR‐069, OMA‐DM)
✓ Semantic (JSON‐LD, Web Thing Model)
✓ Multi‐layer Frameworks (Alljoyn, IoTivity, Weave, Homekit)
Source: Internet of Things Protocols (Online)

Introduction to Internet of Things 5

7
2

572

IOT COMMUNICATION TECHNOLOGIES

• Focus on technologies that enable communication between the IoT devices, networks, and remote
infrastructures
• Six groups:
• 1) Infrastructure protocols,
• 2) discovery protocols,
• 3) DATA PROTOCOLS
• 4) identification protocols
• 5) device management protocols,
• 6) semantic protocols

573

19
 16-02-2023

• Designed to enable the

functionalities with various
IoT networks and
implementations such as
routing, data management,
event handling,
identification, remote
management, and
interoperability

574

TERMS ASSOCIATED WITH IOT NETWORKS

• Constrained nodes
❑Internet-communication feature are not available.
❑Due to constraints of costs, size, weight and available power for functioning.
❑ Restrictions of memory and processing power limit the usage of these nodes.
❑Example: most of these nodes have a severely limited layer 2 capability and often lack full
connectivity features and broadcasting capabilities.
❑ Use in networks and networked applications require special design considerations.
❑Issues of energy optimization and bandwidth utilization are associated with these nodes

575

20
 16-02-2023

CONSTRAINED NETWORKS

• Those networks in which some or all of the constituent nodes are limited in usage aspects due to the
following constraints:
• limited processing power resulting in restrictions on achieving smaller duty cycles
• low data rates and low throughput.
• asymmetric links and increased packet losses.
• restrictions on supported packet sizes due to increased packet losses.
• lack of advanced layer 3 functions such as multicasting and broadcasting.
• limited temporal device reachability from outside the network due to the inclusion of sleep states for
power management in the devices

576

TYPES OF CONSTRAINED DEVICES

• Class 0:
• These devices are severely constrained regarding resources and capabilities.
• The barely feasible memory and processing available in these classes of devices do not
allow for direct communication to the Internet.
• Even if the devices manage to communicate to the Internet directly, the mechanisms in
place for ensuring the security of the device are not supported at all due to the device’s
reduced capabilities.
• Typically, this class of device communicates to the Internet through a gateway or a proxy

577

21
 16-02-2023

• Class 1:
• These devices are constrained concerning available code space and processing power.
• They can primarily talk to the Internet but cannot employ a regular full protocol stack such as HTTP
(hyper text transfer protocol).
• Specially designed protocols stacks such as CoAP (common offer acceptance portal) can be used to
enable Internet-based communication with other nodes.
• Compared to Class 0 devices, Class 1 devices have a comparatively increased power budget, which is
attributed to the increased functionalities it supports over Class 0 devices.
• This class of devices does not need a gateway for accessing the Internet and can be armed with security
features for ensuring safer communication over the Internet

578

• Class 2:
• These devices are functionally similar to regular portable computers such as laptops and
PDAs (personal digital assistants).
• They have the ability and capacity to support full protocol stacks of commonly used
protocols such as HTTP, TLS, and others.
• However, as compared to the previous two classes of devices, these devices have a
significantly higher power budget

579

22
 16-02-2023

LOW POWER AND LOSSY NETWORKS-LLN

• Low power and lossy networks (LLNs) typically comprise devices or nodes with limited
power, small usable memory space, and limited available processing resources.
• The network links between the devices in this network may be composed of low power Wi-Fi
or may be based on the IEEE 802.15.4.
• The physical layers of the devices comprising LLNs are characterized by high variations in
delivery rates significant packet losses, and other similar behavior, which makes it quite
unreliable, and often compromises network stability.
• However, LLNs have found extensive use in application areas such as industrial automation
and monitoring, building automation, smart healthcare, smart homes, logistics, environment
monitoring, and energy management

580

INFRASTRUCTURE PROTOCOLS

• Internet Protocol Version 6 (IPv6),

• Lightweight On-demand Ad hoc Distance vector Routing Protocol–Next Generation
(LOADng)
• Routing Protocol for Low-Power and Lossy Networks (RPL)
• IPv6 over Low-Power Wireless Personal Area Networks (6LoWPAN),
• Quick UDP Internet Connection (QUIC)
• micro IP (uIP)
• nanoIP and Content-Centric Networking (CCN)

581

23
 16-02-2023

CONTENT-CENTRIC NETWORKING (CCN)

• The content-centric networking (CCN) paradigm is more commonly known as information-centric

networking (ICN).
• Other names associated with this paradigm are named data networking (NDN) and publish–subscribe
networking (PSIRP).
• CCN enables communication by defining and adhering to the concept of uniquely named data.
• This networking paradigm, unlike conventional networking approaches, is independent of location,
application, and storage requirements.
• CCN is anchorless, which enables mobility and focuses on in-network caching for operations.
• These measures extend the features of data and communication efficiency, enhances scalability, and
robustness, even in constrained and challenged networks.

582

583

24
 16-02-2023

584

585

25
 16-02-2023

586

• Figure shows the operation of a

typical CCN paradigm.
• Users can access cached content
from multiple content generating
sources
• They access data from trusted
content servers.
• They also enable security of the data

587

26
 16-02-2023

• The CCN request is a hierarchical sequence of network path segments

• In CCN, a forwarder checks a named request through hierarchical prefix matching (typically, longest
prefix match) with a forwarding information base (FIB).
• A binary comparison is performed for prefix matching.
• FIB matching is then used to forward the named request to the appropriate network or network
segment.
• Forwarder has to additionally determine the reverse path from the responder to the requester.
• All these operations are carried out without specifically binding a request to a network end point.
• FIB stores information in a table, at each CCN router which is updated by a routing mechanism.

588

DISCOVERY PROTOCOL: 1) PHYSICAL WEB

• Designed to provide its users with the ability to interact with physical objects and locations seamlessly.
• The information to the users can be in the form of regular web pages or even dynamic web applications
• The main takeaway of this concept is the seamless integration of several standalone smart systems
through the web to provide information on demand to its users
• Examples:
• User-friendly buses, which can alert its users about various route-related information,
• Smart home appliances that can teach new users how to use them,
• Self-diagnostic robots and machinery in industries
• Smart pet tags which can provide information about the pet’s owner and its home location

589

27
 16-02-2023

• The physical web broadcasts a list of URLs within a short radius around it so that anyone
in range can see the available URLs and interact with them.
• This paradigm is primarily built upon Bluetooth low energy (BLE), which is used to
broadcast the content as beacons.
• The primary requirement of any supporting beacons to function in the physical web and
broadcast URLs is their ability to support the Eddystone protocol specification.
• BLE was primarily chosen for the physical web due to its ubiquity, efficiency, and extended
battery life of several years

590

• URLs are one of the core principles of the web and can be either flexible or decentralized.
• These URLs allow any application to have a presence on the web and enables the digital
presence of an object or thing.
• As of now, physical web deployments have been undertaken in public spaces, and any device
with a physical web scanner can detect these URLs.
• The use of URLs extends the benefits of the web security model to the physical web.
• Features such as secured login, secure communication over HTTPS (HTTP over secure
socket layer), domain obfuscation, and others can be easily integrated with the physical web.

591

28
 16-02-2023

MULTICAST DNS (MDNS)

• The multicast domain name system or mDNS is explicitly designed for small networks and is
analogous to regular DNS (domain name system), which is tasked with the resolution of IP
addresses.

• Interestingly, this system is free from any local name server from an operational point of view.
• However, it can work with regular DNS systems as it is a zero-configuration service. It uses
multicast UDP for resolving host names.

• An mDNS client initiates a multicast query on the IP network, which asks a remote host to identify
itself.

• The mDNS cache in the associated network subnet is updated with the multicast response
received from the target.

592

• A node can give up its claim to a domain name by setting the time-to-live (TTL) field to
zero in its response packet to an mDNS query.
• Some popular implementations of mDNS include the Apple Bonjour service and the
networked printer discovery service in Windows 10 operating system from Microsoft.
• The main drawback of mDNS is its host name resolution reach to a top-level domain
only.

593

29
 16-02-2023

UNIVERSAL PLUG AND PLAY

594

595

30
 16-02-2023

UNIVERSAL PLUG AND PLAY

• Universal plug and play or UPnP encompasses a set of networking protocols aimed at service discovery
and the establishment of functional network-based data sharing and communication services
• Mainly used for enabling dynamic connections of devices to computing platforms.
• UPnP allows the devices attaching to a computer network to configure themselves and update their
hosts about their working configurations over a network.
• UPnP is managed by the Open Connectivity Foundation.
• UPnP’s scope includes the discovery and intercommunication between networked devices such as
mobiles, printers, access points, gateways, televisions, and other regular commercial systems enabled with
IP capabilities..

596

597

31
 16-02-2023

598

599

32
 16-02-2023

• Figure outlines the

underlying UPnP stack
and the relative
location of the various
functionalities in the
stack

600

601

33
 16-02-2023

602

• The present-day UPnP has been designed to run on IP enabled networks, and makes use of
the networking services of HTTP, XML, and SOAP for data transfer, device descriptions, and
event generation and monitoring.
• UPnP enables UDP-based HTTP device search requests and advertisements using
multicasting.
• The responses to device requests are necessarily unicast.
• UPnP advertisements use UDP port 1900 for multicasting.
• The unnecessary overheads and traffic generated by UPnP systems and their multicast
behavior make them unsuitable for enterprise systems

603

34
 16-02-2023

FUNCTIONALITY-BASED IOT
PROTOCOL ORGANIZATION
✓ Connectivity (6LowPAN, RPL)
✓ Identification (EPC, uCode, IPv6, URIs)
✓ Communication / Transport (WiFi, Bluetooth, LPWAN)
✓ Discovery (Physical Web, mDNS, DNS‐SD)
✓ Data Protocols (MQTT, CoAP, AMQP, Websocket, Node)
✓ Device Management (TR‐069, OMA‐DM)
✓ Semantic (JSON‐LD, Web Thing Model)
✓ Multi‐layer Frameworks (Alljoyn, IoTivity, Weave, Homekit)
Source: Internet of Things Protocols (Online)

Introduction to Internet of Things 6

0
4

604

MQTT

Introduction to Internet of Things 6

0
5

605

35
 16-02-2023

INTRODUCTION
✓ Message Queue Telemetry Transport.
✓ ISO standard (ISO/IEC PRF 20922).
✓ It is a publish‐subscribe‐based lightweight messaging protocol for
use in conjunction with the TCP/IP protocol.
✓ MQTT was introduced by IBM in 1999 and standardized by OASIS in
2013.
✓ Designed to provide connectivity (mostly embedded) between
applications and middle‐wares on one side and networks and
communications on the other side.
Source: “MQTT”, Wikipedia (Online)

Introduction to Internet of Things 6

0
6

606

✓ A message broker controls the publish‐subscribe messaging

pattern.
✓ A topic to which a client is subscribed is updated in the form
of messages and distributed by the message broker.
✓ Designed for:
▪ Remote connections
▪ Limited bandwidth
▪ Small‐code footprint

Source: “MQTT”, Wikipedia (Online)

Introduction to Internet of Things 6

0
7

607

36
 16-02-2023

MQTT
COMPONENTS

Publishers • Lightweight sensors

Subscribers • Applications interested in sensor data

Brokers • Connect publishers and subscribers

• Classify sensor data into topics

Source: “MQTT”, Wikipedia (Online)

Introduction to Internet of Things 6

0
8

608

MQTT
METHODS

Connect
Disconnect
Subscribe
Unsubscribe
Publish

Source: “MQTT”, Wikipedia (Online)

Introduction to Internet of Things 6

0
9

609

37
 16-02-2023

Source: “MQTT 101 – How to Get Started with the lightweight IoT Protocol”, HiveMQ (Online)

Introduction to Internet of Things 6

1
0

610

COMMUNICATION

✓ The protocol uses a publish/subscribe architecture (HTTP uses a

request/response paradigm).
✓ Publish/subscribe is event‐driven and enables messages to be
pushed to clients.
✓ The central communication point is the MQTT broker, which is in
charge of dispatching all messages between the senders and the
rightful receivers.
✓ Each client that publishes a message to the broker, includes a topic
into the message. The topic is the routing information for the
broker.
Source: “MQTT 101 – How to Get Started with the lightweight IoT Protocol”, HiveMQ (Online)

Introduction to Internet of Things 6

1
1

611

38
 16-02-2023

✓ Each client that wants to receive messages subscribes to a

certain topic and the broker delivers all messages with the
matching topic to the client.
✓ Therefore the clients don’t have to know each other. They
only communicate over the topic.
✓ This architecture enables highly scalable solutions without
dependencies between the data producers and the data
consumers.

Source: “MQTT 101 – How to Get Started with the lightweight IoT Protocol”, HiveMQ (Online)

Introduction to Internet of Things 6

1
2

612

MQTT TOPICS

✓ A topic is a simple string that can have more hierarchy levels,

which are separated by a slash.
✓ A sample topic for sending temperature data of the living
room could be house/living‐room/temperature.
✓ On one hand the client (e.g. mobile device) can subscribe to
the exact topic or on the other hand, it can use a wildcard.

Source: “MQTT 101 – How to Get Started with the lightweight IoT Protocol”, HiveMQ (Online)

Introduction to Internet of Things 6

1
3

613

39
 16-02-2023

✓ The subscription to house/+/temperature would result in all

messages sent to the previously mentioned topic house/living‐
room/temperature, as well as any topic with an arbitrary value in
the place of living room, such as house/kitchen/temperature.
✓ The plus sign is a single level wild card and only allows arbitrary
values for one hierarchy.
✓ If more than one level needs to be subscribed, such as, the entire
sub‐tree, there is also a multilevel wildcard (#).
✓ It allows to subscribe to all underlying hierarchy levels.
✓ For example house/# is subscribing to all topics beginning with
house.
Source: “MQTT 101 – How to Get Started with the lightweight IoT Protocol”, HiveMQ (Online)

Introduction to Internet of Things 6

1
4

614

APPLICATIONS

✓ 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.

Introduction to Internet of Things 6

1
5

615

40
 16-02-2023

SMQTT

✓ Secure MQTT is an extension of MQTT which uses encryption

based on lightweight attribute based encryption.
✓ The main advantage of using such encryption is the broadcast
encryption feature, in which one message is encrypted and
delivered to multiple other nodes, which is quite common in
IoT applications.
✓ In general, the algorithm consists of four main stages: setup,
encryption, publish and decryption.
Source: M. Singh, M. Rajan, V. Shivraj, and P.Balamuralidhar, "Secure MQTT for Internet of Things (IoT)," in Fifth International Conference on
Communication Systems and Network Technologies (CSNT 2015), April 2015, pp. 746‐751

Introduction to Internet of Things 6

1
6

616

✓ In the setup phase, the subscribers and publishers register

themselves to the broker and get a master secret key according to
their developer’s choice of key generation algorithm.
✓ When the data is published, it is encrypted and published by the
broker which sends it to the subscribers, which is finally decrypted
at the subscriber end having the same master secret key.
✓ The key generation and encryption algorithms are not standardized.
✓ SMQTT is proposed only to enhance MQTT security features.

Source: M. Singh, M. Rajan, V. Shivraj, and P.Balamuralidhar, "Secure MQTT for Internet of Things (IoT)," in Fifth International Conference on
Communication Systems and Network Technologies (CSNT 2015), April 2015, pp. 746‐751

Introduction to Internet of Things 6

1
7

617

41
 16-02-2023

MQTT: DATA PROTOCOL

• Message queue telemetry transport or MQTT is a simple, lightweight publish– subscribe

protocol, designed mainly for messaging in constrained devices and networks
• It provides a one-to-many distribution of messages and is payload content agnostic.
• MQTT works reliably and flawlessly over high latency and limited bandwidth of unreliable
networks without the need for significant device resources and device power.
• The MQTT paradigm consists of numerous clients connecting to a server; this server is
referred to as a broker.

618

• The clients can have the roles of information publishers (sending messages to the broker)
or information subscribers (retrieving messages from the broker).
• This allows MQTT to be largely decoupled from the applications being used with MQTT

619

42
 16-02-2023

OPERATIONAL PRINCIPLE

• MQTT is built upon the principles of hierarchical topics and works on TCP for
communication over the network.
• Brokers receive new messages in the form of topics from publishers.
• A publisher first sends a control message along with the data message.
• Once updated in the broker, the broker distributes this topic’s content to all the subscribers
of that topic for which the new message has arrived.
• This paradigm enables publishers and subscribers to be free from any considerations of the
address and ports of multiple destinations/subscribers or network considerations of the
subscribers, and vice versa.

620

• In the absence of any subscribers of a topic, a broker normally discards messages

received for that topic unless specified by the publisher otherwise
• This feature removes data redundancies and ensures that maximally updated information
is provided to the subscribers
• It also reduces the requirements of storage at the broker.
• The publishers can set up default messages for subscribers in agreement with the broker
if the publisher’s connection is abruptly broken with the broker.
• This arrangement is referred to as the last will and testament feature of MQTT.

621

43
 16-02-2023

• Multiple brokers can communicate in order to connect to a subscriber’s topic if it is not

present directly with the subscriber’s primary broker
• MQTT’s control message sizes can range between 2 bytes to 256 megabytes of data, with a
fixed header size of 2 bytes. This enables the MQTT to reduce network traffic significantly.
• The connection credentials in MQTT are unencrypted and often sent as plain text.
• The responsibility of protecting the connection lies with the underlying TCP layer
• The MQTT protocol provides support for 14 different message types, which range from
connect/disconnect operations to acknowledgments of data.

622

• (I) CONNECT: Publisher/subscriber request to connect to the broker.

• (ii) CONNACK: Acknowledgment after successful connection between publisher/ subscriber and broker.
• (iii) PUBLISH: Message published by a publisher to a broker or a broker to a subscriber.
• (iv) PUBACK: Acknowledgment of the successful publishing operation.
• (v) PUBREC: Assured delivery component message upon successfully receiving publish.
• (vi) PUBREL: Assured delivery component message upon successfully receiving publish release signal.
• (vii) PUBCOMP: Assured delivery component message upon successfully receiving publish completion.

623

44
 16-02-2023

• (viii) SUBSCRIBE: Subscription request to a broker from a subscriber.

• (ix) SUBACK: Acknowledgment of successful subscribe operation.
• (x) UNSUBSCRIBE: Request for unsubscribing from a topic.
• (xi) UNSUBACK: Acknowledgment of successful unsubscribe operation.
• (xii) PINGREQ: Ping request message. (xiii) PINGRESP: Ping response message.
• (xiv) DISCONNECT: Message for publisher/subscriber disconnecting from the broker.

624

MQTT MESSAGE DELIVERY QOS

• Content delivery mechanisms are primarily designed for message transmission over
constrained networks and through constrained devices.
• At most once: This is a best-effort delivery service and is dependent on the best delivery
efforts of the TCP/IP network on which the MQTT is supported. It may result in message
duplication or loss.
• At least once: This delivery service guarantees assured delivery of messages. However,
message redundancy through duplication is a possibility.
• Exactly once: This delivery service guarantees assured message delivery. This service also
prevents message duplication

625

45
 16-02-2023

• These are the three levels of MQTT QoS:

• QoS 0:
• This is a best-effort and unacknowledged data service referred to as “at most once”
delivery.
• The publisher sends its message one time to a server, which transmits it once to the
subscribers.
• No response is sent by the receiver, and no retry is performed by the sender
• The message arrives at the receiver either or not at all

626

QOS 1:

• This QoS level ensures that the message delivery between the publisher and server and
then between the server and subscribers occurs at least once.
• In PUBLISH and PUBACK packets, a packet identifier is included in the variable header.
• If the message is not acknowledged by a PUBACK packet, it is sent again.
• This level guarantees “at least once” delivery

627

46
 16-02-2023

QOS 2:

• This is the highest QoS level, used when neither loss nor duplication of messages is acceptable.
• Confirming the receipt of a PUBLISH message requires a two-step acknowledgement process.
• The first step is done through the PUBLISH/PUBREC packet pair and the second is achieved with the
PUBREL/PUBCOMP packet pair.
• This level provides a “guaranteed service” known as “exactly once” delivery, with no consideration for
the number of retries as long as the message is delivered once.
• QoS process is symmetric in regard to the roles of sender and receiver, but two separate transactions
exist.
• One transaction occurs between the publishing client and the MQTT server, and the other transaction
happens between the MQTT server and the subscribing client

628

COAP

• The constrained application protocol, or CoAP as it is more popularly known, is designed for
use as a web transfer protocol in constrained devices and networks, which are typically low
power and lossy.
• The constrained devices typically have minimal RAM and an 8-bit processor at most
• CoAP can efficiently work on such devices, even when these devices are connected to highly
lossy networks with high packet loss, high error rates, and bandwidth in the range of kilobits
• CoAP follows a request–response paradigm for communication over these lossy networks.
• Additional highlights of this protocol include support for service discovery, resource
discovery, URIs (uniform resource identifier), Internet media handling support, easy HTTP
integration, and multicasting support, that too while maintaining low overheads.

629

47
 16-02-2023

• CoAP implementations can act as both clients and servers (not simultaneously).
• A CoAP client’s request signifies a request for action from an identified resource on a
server, which is similar to HTTP.
• The response sent by the server in the form of a response code can contain resource
representations as well.
• CoAP interchanges are asynchronous and datagram-oriented over UDP.

630

• Figure shows the placement of CoAP in

a protocol stack.
• The two seemingly distinct layers of
messaging (which handle the UDP and
asynchronous messaging) and request-
response (which handles the connection
establishment) are part of the CoAP
header.

631

48
 16-02-2023

COAP FEATURES

• It has suitable web protocol for integrating IoT and M2M services in constrained environments
with the Internet.

• CoAP enables UDP binding and provides reliability concerning unicast as well as multicast requests.
• Message exchanges between end points in the network or between nodes is asynchronous.

• The limited packet header incurs significantly lower overheads. This also results in less complexity
and processing requirements for parsing of packets.

• CoAP has provisions for URI and other content-type identifier support. CoAP additionally provides
DTLS (datagram transport layer security) binding.

632

• It has a straightforward proxy mechanism and caching capabilities, which is responsible

for overcoming the effects of the lossy network without putting extra constraints on the
low-power devices. The caching is based on the concept of the maximum age of packets.
• The protocol provides a stateless mapping with HTTP. The server or receiving node does
not retain information about the source of the message; rather, it is expected that the
message packet carries that information with it. This enables CoAP’s easy and uniform
integration with HTTP.

633

49
 16-02-2023

COAP MESSAGING

• CoAP defines four messaging types:

• 1) Confirmable (CON),
• 2) non-confirmable (NON),
• 3) acknowledgment (ACK), and
• 4) reset.
• The method codes and the response codes are included in the messages being carried.
• These codes determine whether the message is a request message or a response message.

634

• Requests are typically carried in confirmable and non-confirmable message types.

• However, responses are carried in both of these message types as well as with the
acknowledgment message.
• The transmission of responses with acknowledgment messages is known as piggybacking
and is quite synonymous with CoAP.

635

50
 16-02-2023

OPERATIONAL PRINCIPLE

• CoAP is built upon the exchange of messages between two or more UDP end points.
• Options and payload follow the compact 4-byte binary header in CoAP.
• This arrangement is typical of request and response messages of CoAP.
• A 2-byte message ID is used with each message to detect duplicates.
• Whenever a message is marked as a CON message, it signifies that the message is reliable.
• In the event of delivery failure of a CON message, subsequent retries are attempted with exponential
back-off until the receiving end point receives an ACK with the same message ID.
• In case the recipient does not have the resources to process the CON message, a RESET message is sent
to the originator of the CON message instead of an ACK message.

636

637

51
 16-02-2023

• Specific messages, which do not require reliable message transmission (such as rapid
temporal readings of the environment from a sensor node), are sent as NON messages.
• NON messages do not receive an acknowledgment
• However, the message ID associated with it prevents duplication.
• NON messages elucidate a NON or CON response from a server, based on the settings
and semantics of the application.
• If the receiver of the NON cannot process the message, a RESET message is sent to the
originator of the NON message

638

• If a server fails to respond immediately to a request received by it in a CON message, an

empty ACK response is sent to the requester to stop request retransmissions.
• Whenever the response is ready, a new CON message is used to respond to the
previous request by the client.
• Here, the client then must respond to the server using an ACK message. This scheme is
known as a separate response

639

52