IOT_MODULE_3.pdf simple example notes for use

IOT NETWORK PROTOCOLS
Network protocols are a set of rules outlining how connected devices communicate
across a network to exchange information easily and safely.

“IP” AS THE IOT NETWORKLAYER
The Internet Protocol (IP) is a protocol, or set of rules, for routing and
addressing “packets of data” so that they can travel across networks and arrive
at the correct destination.

An IP address identifies every device connected to the internet. This enables
computers and other internet-connected devices, such as mobile phones and
Internet-of-Things (IoT) devices, to communicate over the internet and on
local-area networks (LANs).
IP addresses are the numbers that enable our computers, servers, telephones,
cameras, printers and sensors to communicate with each other. Without IP
addresses, we would have to copy data from device to device manually, using
CDs, DVDs, hard disks or flash storage, such as a USB drive.
WHY “IP”..???

1.Packet Structure
2. Addressing
3. Routing
4. Fragmentation and Reassembly
5. Error Handling
6. Versioning
What are “IP” Rules ?

The Business case for IP
A business case is like a plan that explains why doing something is a good idea,
showing the reasons it will help and how much it might cost.
IP (Internet Protocol) is the system that assigns unique addresses to devices on a
network, allowing them to communicate. It ensures data packets are delivered to
the right destination across the internet.
In short:- (IP (Internet Protocol) is like the postman of the internet, making sure
messages get from one place to another.)
In a business context, IP (Internet Protocol) is essential for enabling
communication between devices, facilitating data exchange, and supporting
various online services crucial for modern business operations.

Reason behind The Business case for IP
1.Standardized Connectivity: IP serves as a standardized protocol enabling
seamless connectivity across diverse networks.
2.Scalable Framework: The scalability of IP allows for the expansion of
digital services and accommodates the growing number of connected devices.
3.Foundation for Internet Communication: IP is the foundational protocol
for internet communication, facilitating data transfer and interactions between
devices.
4.Global Interoperability: IP's global adoption ensures interoperability,
enabling devices and systems from different vendors to communicate
effectively.
5.Support for Digital Services: The widespread use of IP is crucial for
supporting various digital services, from web browsing to online transactions,
fostering business growth and innovation.

Key advantage of The Business case for IP
Open and standards-based
Versatile
Ubiquitous
Scalable
Manageable and highly secure
Stable and resilient
Consumers’ market adoption
The innovation factor

1) Open and standards-based: IP follows open standards, ensuring compatibility
and interoperability.
2) Versatile: IP is adaptable to diverse applications and technologies.
3) Ubiquitous: IP is widely present and used across global networks.
4) Scalable: IP accommodates network expansion as demand grows.
5) Manageable and highly secure: IP networks are effectively managed and offer
robust security measures.
6) Stable and resilient: IP provides stability and resilience to network disruptions.
7) Consumers’ market adoption: IP is widely adopted in consumer markets,
driving technology use.
8) The innovation factor: IP fosters innovation by supporting a variety of
applications and services.

Adaptation of the Internet Protocol
How to implement IP in data center, cloud services, and operation centers
hosting IoT applications may seem obvious,
but the adoption of IP in the last mile is more complicated and often makes
running IP end-to-end more difficult.
Adaptation means application layered gateways (ALGs) must be implemented to
ensure the translation between non-IP and IP layers.
involves replacing all non-IP layers with their IP layer counterparts, simplifying
the deployment model and operations.

The following factors determine which model is best suited for
last-mile connectivity
Bidirectional versus unidirectional data flow
Overhead for last-mile communications paths
Data flow model
Network diversity

1. Bidirectional versus unidirectional data flow: Refers to the directionality of
data transmission, where bidirectional allows two-way communication, and
unidirectional allows data to flow in one direction only.
2. Overhead for last-mile communications paths: Involves the additional data
processing or resource utilization required for the final segment of a
communication path, typically between the service provider and end-user.
3. Data flow model: Describes the pattern in which data moves through a system,
outlining how it is processed, stored, and transferred between different
components or nodes.
4. Network diversity: Involves having a variety of network types or technologies
within an infrastructure, providing resilience, flexibility, and optimized
performance based on specific requirements.

The Need for Optimization
Refers to the necessity for improving efficiency, performance, or resource
utilization in a given process, system, or operation.
Constrained Nodes
Constrained Networks
IP Versions

Constrained Nodes
Small devices with limited CPU, memory, and power resources, so- called
"constrained devices"
(often used as sensors/actuators, smart objects, or smart devices) can form a
network, becoming "constrained nodes" in that network.

Constrained Networks
A constrained network is composed of a significant portion of constrained nodes.
Mostly, these constrained node networks are deployed in the edge network of an IoT
system.
In a constrained domain, you need to optimize performance within those constraints.
Examples:-
micro controller, smart devices, sensors and actuators, and other small
computers like that.

IP Version’s
IP versions refer to the two main protocols for internet communication: IPv4,
which uses 32-bit addresses, and IPv6, which uses 128-bit addresses.

Some of the main factors applicable to IPv4 and IPv6 support in an IOT
solution:
Application Protocol:- IOT devices implementing Ethernet or Wi-Fi interfaces
can communicate over both IPv4 and IPv6, but the application protocol may
dictate the choice of the IP version.
Cellular Provider and Technology:- IoT devices with cellular modems are
dependent on the generation of the cellular technology as well as the data
services offered by the provider.
Serial Communications:- Many legacy devices in certain industries, such as
manufacturing and utilities, communicate through serial lines. Data is transferred
using either proprietary or standards based protocols, such as DNP3, Modbus, or
IEC 60870-5-101.
IPv6 Adaptation Layer:- IPv6-only adaptation layers for some physical and
data link layers for recently standardized IoT protocols support only IPv6.

Optimizing IP for IoT
Internet Protocol is key for a successful Internet of Things, constrained nodes
and constrained networks mandate optimization at various layers and on multiple
protocols of the IP architecture. The following sections introduce some of these
optimizations already available from the market or under development by the
IETF(Internet Engineering Task Force).

The adaptation layer in the IoT protocol stack was created to address the
diverse and fragmented nature of IoT devices and networks. It provides a
standardized interface for different IoT devices and networks to communicate
with each other, regardless of the underlying technologies and protocols they
use

Existing Optimizing for IOT using IP
From 6LoWPAN to 6Lo (IPv6 over Low-power Wireless Personal Area Networks.)
6Lo Working Group (IPv6 over Networks of Resource-constrained Nodes)
6TiSCH (IPv6 over the TSCH mode of IEEE 802.15. 4 (6TiSCH))
(Time Slotted Channel Hopping or Time Synchronized Channel Hopping)
RPL (Routing Protocol for Low-power and lossy networks)

From 6LoWPAN to 6Lo
The main examples of adaptation layers optimized for constrained nodes or “things”
are the ones under the6LoWPANworking group and its successor, the 6Lo working
group.
The initial focus of the 6LoWPAN working group was to optimize the transmission
of IPv6 packets over constrained networks such as IEEE 802.15.4.
Figure shows an example of an IoT protocol stack using the 6LoWPAN adaptation
layer beside the well- known IP protocol stack for reference.

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.
Some examples of typical 6LoWPAN header stacks.

 Header Compression (RFC4944 and RFC 6282)
The capability shrinks the size of IPv6’s 40-byte headers and User Datagram
Protocol’s (UDP’s) 8- byte headers down as low as 6 bytes combined in some
cases

 Fragmentation
The maximum transmission unit (MTU) for an IPv6 network must be at least 1280
bytes.
The fragment header utilized by 6LoWPAN is composed of three primary fields:
Datagram Size :- The 1-byte Datagram Size field specifies the total size of the un
fragmented payload.
Datagram Tag:- Datagram Tag identifies the set of fragments for a payload.
Datagram Offset:- Datagram Offset field delineates how far into a payload a
particular fragment occurs

Mesh Addressing
The purpose of the 6LoWPANmesh addressing function is to forward packets over
multiple hops.
Three fields are defined for this header:
1. Hop Limit
2. Source Address
3. Destination Address
The hop limit for mesh addressing also provides an upper limit on how many times
the frame can be forwarded.
Each hop decrements this value by 1 as it is forwarded. Once the value hits 0, it is
dropped and no longer forwarded.

6Lo Working group
With the work of the 6LoWPAN working group completed, the 6Lo working
group seeks to expand on this completed work with a focus on IPv6
connectivity over constrained-node networks.
6lo focuses on the work that facilitates IPv6 connectivity over. constrained
node networks with the characteristics of:
1. limited power, memory and processing resources.
2. hard upper bounds on state, code space and processing cycles.
3. optimization of energy and network bandwidth usage.
It works great with open IP standard including TCP, UDP, HTTP, COAP,
MATT and web-sockets.

This working group is focused on the following:
1. IPv6-over-foo adaptation layer specifications using 6LoWPAN technologies
(RFC4944, RFC6282, RFC6775) for link layer technologies.
1) IPv6 over Bluetooth Low Energy
2) Transmission of IPv6 packets over near-field communication IPv6 over
802.11ah
3) Transmission of IPv6 packets over DECT Ultra Low Energy
4) Transmission of IPv6 packets on WIA-PA (Wireless Networks for
Industrial,Automation– Process Automation)
5)Transmission of IPv6 over Master Slave/Token Passing (MS/TP)
2. Information and data models such as MIB modules:
3. Optimizations that are applicable to more than one adaptation layer specification
4. Informational and maintenance publications needed for the IETF specifications in
this area

6TiSCH
Devices implementing IEEE 802.15.4e TSCH communicate by following a Time
Division Multiple Access (TDMA) schedule.
An allocation of a unit of bandwidth or time slot is scheduled between neighbor
nodes. (This allows the programming of predictable transmissions and enables
deterministic, industrial-type applications.)
To standardize IPv6 over the TSCH mode of IEEE 802.15.4e (known as
6TiSCH), the IETF formed the 6TiSCH working group. This working group works
on the architecture, information model, and minimal 6TiSCH configuration,
leveraging and enhancing work done by the 6LoWPAN working group, RoLL
working group, and CoRE working group.

An important elements pacified by the 6TiSCH working group is 6top, a sub layer
that glues together the MAC layer and 6LoWPAN adaptation layer.

The 6TiSCH architecture defines four schedule management mechanisms
Static scheduling
Neighbor-to-neighbor scheduling
Remote monitoring and scheduling management
Hop-by-hop scheduling

•Static scheduling: All nodes in the constrained network share a fixed schedule. Cells
are shared, and nodes contend for slot access in a slotted aloha manner. Slotted aloha
is a basic protocol for sending data using time slot boundaries when communicating
over a shared medium. Static scheduling is a simple scheduling mechanism that can
be used upon initial implementation or as a fallback in the case of network
malfunction. The drawback with static scheduling is that nodes mayexpect a packet
at any cell in the schedule. Therefore, energy is wasted idly listening across all cells.
• Neighbor-to-neighbor scheduling: A schedule is established that correlates with the
observed number of transmissions between nodes. Cells in this schedule can be
added or deleted as traffic requirements and bandwidth needs change.

• Remote monitoring and scheduling management: Time slots and other resource
allocation are handled by a management entity that can be multiple hops away. The
scheduling mechanism leverages 6top and even CoAP in some scenarios. This scheduling
mechanism provides quite a bit of flexibility and control in allocating cells for
communication between nodes.
• Hop-by-hop scheduling: A node reserves a path to a destination node multiple hops
away by requesting the allocation of cells in a schedule at each intermediate node hop in
the path. The protocol that is used by a node to trigger this scheduling mechanism is not
defined at this point.

In addition to schedule management functions, the 6TiSCH architecture also
defines three different forwarding models.
•TrackForwarding (TF): This is the simplest and fastest forwarding model. A
“track” in this model is a unidirectional path between a source and a destination.
This track is constructed by pairing bundles of receive cells in a schedule with a
bundle of receive cells set to transmit. So, a frame received within a particular cell
or cell bundle is switched to another cell or cell bundle. This forwarding occurs
regardless of the network layer protocol.
•Fragmentforwarding (FF): This model takes advantage of 6LoWPAN
fragmentation to build a Layer 2 forwarding table. IPv6 packets can get
fragmented at the 6LoWPAN sublayer to handle the differences between IEEE
802.15.4 payload size and IPv6 MTU. Additional headers for RPL source route
information can further contribute to the need for fragmentation. However, with
FF, a mechanism is defined where the first fragment is routed based on the IPv6
header present. The 6LoWPANsublayer learns the next-hop selection of this first
fragment, which is then applied to all subsequent fragments of that packet.
Otherwise, IPv6 packets undergo hop-by-hop reassembly. This increases latency
and can be power- and CPU-intensive for a constrained node.

• IPv6 Forwarding (6F): This model forwards traffic based on its IPv6 routing table.
Flows of packets should be prioritized by traditional QoS (quality of service) and RED
(random early detection) operations. QoS is a classification scheme for flows based on
their priority, and RED is a common congestion avoidance mechanism.

1. RPL Basics: RPL is like a rulebook for devices to find their way in a network.
It's made by IETF in a group called the RoLL team, and they wrote down all the
rules in a document called RFC 6550.
2. Mesh Network: imagine in the network is like a mini-router, all linked together
in a web. They can talk directly to each other without needing a big central router.
3. Routing at the IP Layer: Each device checks every message it gets and decides
where to send it next based on the address written on it. They don't need to know
about the technical details of how the messages are sent; they just look at the
address.
4. Storing and Non-Storing Modes: Some devices keep a full list of routes in their
memory (storing mode), while others only remember their closest connections
(non-storing mode) to save space and work faster.
RPL

5. Directed Acyclic Graph (DAG): Think of a DAG like a map showing all the
routes without any loops. RPL uses this map to plan the best paths for messages
to travel. A special type of DAG called a DODAG is used, which is like a map
with one main destination (the DODAG root).
6. Building a DODAG: RPL creates a special kind of map (DODAG) where all
roads lead to one main destination. It's like drawing lines from all over to one
central point. This main point is often a border router, which is like the gateway to
the outside world for the network.

1. Objective Function (OF): Think of the objective function like a set of rules
that helps devices in a network decide the best routes to send data. It's like a
guide that tells them which paths are better based on certain factors, such as how
many times data needs to be transmitted.
2. Rank: The rank is like a score that each device gives itself to show how
important it is in the network. It helps prevent data from going in circles and
getting lost. Devices increase their rank if they receive certain messages, but they
can also lower it if they find better routes.

3. RPL Headers: These are special labels attached to data packets in a network.
They help devices understand where the data needs to go and how to get it there.
RFC 6553: This standard defines a special label called the RPL option. It's
like a tag that helps devices detect and prevent data from going in loops. It's
added to packets to make sure they follow a straight path without getting stuck.
RFC 6554: This standard specifies another label called the Source Routing
Header (SRH). It's used by border routers or the main destination in the
network to show the best path for data to travel downstream to other devices.
It's like giving the data a clear map to follow.

METRICS
RPL, a routing protocol, comes with new rules and limits (metrics and constraints)
for guiding data in networks. It's designed to work well for both devices that stay
plugged in and those that run on batteries. These rules are more complete than what
other routing protocols offer. Some of these rules include:
1. Expected Transmission Count (ETX): Measures how many transmissions a
device expects to make for a message.
2. Hop Count: Counts the number of stops (hops) a message makes on its way to
the destination.
3. Latency: Measures how long it takes for a message to travel between devices.
4. Link Quality Level: Rates the reliability of the connection between devices.
5. Link Color: Assigns colors to paths to influence routing decisions.

6. Node State and Attribute: Identifies nodes managing traffic and those struggling with
workload or resources.
7. Node Energy: Checks how much power a device has left to conserve energy.
8. Throughput: Measures the amount of data that can be sent through a connection.

The information about authentication and encryption on constrained nodes:
1. ACE (Authentication and Authorization for Constrained Environments)
ACE is a group that looks at how to make sure only authorized users can access
devices in IOT networks. They focus on using protocols like CoAP (Constrained
Application Protocol) with DTLS (Datagram Transport Layer Security) to protect
data.
Their goal is to create a standard way for devices to prove who they are and what
they can access. This helps control access to resources like files or sensors, even in
small devices.
2. DICE (DTLS in Constrained Environments)
DICE is another group that focuses on securing communication in IOT networks,
especially when devices have limited resources like power or memory.
They work on making DTLS (a type of encryption) work well in these constrained
environments. They're figuring out how to make DTLS work efficiently for
devices with limited capabilities, like securing messages sent to multiple devices
at once.

Profiles and Compliances
Profiles in the context of IoT are standardized sets of
protocols and specifications that dictate how devices
communicate and interact within a network. They
define the rules, formats, and standards for data
exchange, ensuring consistency and interoperability
among IoT devices from different manufacturers.
Profiles serve as guidelines for device design and
implementation, facilitating seamless integration and
operation in IoT ecosystems.
Compliances in IoT are certifications or
validations that confirm a device's adherence
to specific profiles or standards. They serve
as assurances of interoperability and quality,
indicating that a device has met the
requirements set forth by industry standards
organizations. Compliances enable
consumers and stakeholders to make
informed decisions when selecting IoT
devices or solutions.

industry organizations working on profile definitions and certifications for IOT
constrained nodes and networks. There are various documents and promotions
from these organizations in the IOT space, so it is worth being familiar with their
goals.
Internet Protocol for Smart Objects (IPSO) Al iance
The IPSO Alliance started in 2008 to encourage using the Internet Protocol (IP)
for making smart things communicate with each other. Now, they focus on
helping people use IP in smart devices better. They test if different smart devices
can talk to each other smoothly and follow the same rules. While they don't make
new technologies, they teach others how to use existing ones properly, making
sure that engineers and product builders know how to create IoT devices the right
way.
The Wi-SUN(Wi-SUN stands for "Wireless Smart Utility Network.")
The Wi-SUN Alliance is a group in the industry working on creating a specific
way for devices to talk to each other. They're mostly focused on a protocol called
IEEE 802.15.4g, which helps with secure communication over the internet. Their
main goal is to improve utility services like electricity or water by making sure
devices can connect securely and reliably, even in different types of areas like
cities or countryside.

The Thread Group
The Thread Group is a collaboration among companies working on smart object
solutions for consumers. They've developed a wireless profile based on IPv6, a
type of internet protocol, which allows more than 250 devices to connect
wirelessly in a low-power mesh network. Thread uses IEEE 802.15.4 wireless
technology, which is different from Wi-SUN's IEEE 802.15.4g.
IPv6 Ready Logo program
Initially, the IPv6 Forum worked to promote IPv6 adoption worldwide. As IPv6
became more widely used, there was a need for a way to ensure devices and
systems could work together smoothly. This led to the creation of the IPv6 Ready
Logo program. This program tests devices to make sure they meet certain
standards for IPv6 compatibility and interoperability. It offers certifications for
different IPv6 components like DHCP, IPsec, and customer edge routers. These
certifications are well-recognized in the industry and help users trust that IPv6-
enabled products will work well together. There's also a new effort to certify
IPv6 compatibility specifically for IOT devices.

Application Protocols for IoT
In IOT networks, traditional application protocols may not be the best fit for
constrained devices and networks. Therefore, we focus on how IOT protocols are
transported, including:
i. The Transport Layer: In IP-based networks, TCP and UDP are commonly
used. However, the constrained nature of IOT networks requires a closer
examination of how these traditional transport methods are used.
ii. IoT Application Transport Methods: This section looks at the different types
of IoT application data and how they are carried across a network.
Usually, TCP or UDP are used to transport IOT application data, similar to
traditional networks. However, with lower-layer IOT protocols, there are often
multiple options available.

The Transport Layer
It is a crucial part of the TCP/IP architecture in IOT networks. There are two main
protocols specified for this layer:
i. Transmission Control Protocol (TCP): This protocol is like making a phone call.
Before data can be exchanged, a connection needs to be established between the
sender and receiver. It ensures reliable data delivery but may introduce some
delays due to the connection setup process.
ii. User Datagram Protocol (UDP): This protocol is like sending a letter. Data can
be sent quickly between sender and receiver, but there's no guarantee that it will be
delivered or received. It's faster than TCP but doesn't provide confirmation of
delivery, similar to sending a letter in the mail.
TCP is preferred for reliable data delivery in traditional networks, while UDP suits
real-time applications. In IOT, choosing between them depends on factors like
data size and network reliability. Newer IOT protocols often favor UDP due to
its lower overhead. Multicast, exclusive to UDP, allows efficient firmware updates
across multiple IOT devices.

IOT Application Transport Methods
The exploration of IoT application transport methods encompasses several
categories:
1. Direct data transport: Data payload is transmitted directly over lower layers
without an application layer protocol.
2. SCADA integration: Industrial SCADA protocols, originally non-IP, have been
adapted for IP networks.
3. Generic web-based protocols: Widely used in consumer and enterprise IoT
devices, including Ethernet, Wi-Fi, and 4G/LTE.
4. IoT-specific protocols: Designed for constrained nodes with limited resources,
such as MQTT and CoAP, optimized for bandwidth constraints on cellular,
satellite, or 6LoWPAN networks.

Direct data transport or Application layer not present
some devices, called class 0 devices according to IETF RFC 7228, can only send or receive a
small amount of data, usually just a few bytes.
These devices are very basic and don't have the capability to use complex networking
protocols like IP, TCP, or UDP.
For instance, think of inexpensive temperature and humidity sensors that transmit data over
LPWA LoRaWAN networks.
They send the temperature and humidity data directly over the network without using TCP/IP
because they have very limited resources.
The data they send is decoded by the receiving application to understand the temperature and
humidity readings.

Different temperature sensors send data in their own way, making it hard for apps to
understand. An IOT data broker translates these varied data formats into a standard
language for easy app interpretation.

In the realm of networking, IOT is a newer concept, while IP serves as the
standard for computer networks. Older protocols, like SCADA, initially used
non-IP methods for sensor and actuator connections before transitioning to IP-
based systems, like Ethernet and IPv4, over time.
SCADA (Supervisory Control And Data Acquisition)

ADAPTING SCADA FOR IP
In the 1990s, special computer systems called SCADA started using regular internet
connections, like Ethernet and IP. This made it easier for them to work with other
computer systems. Older SCADA systems had to be changed a bit to work with the
internet, but this helped companies use their old equipment while upgrading to new
networks.
For example, a protocol called DNP3, used to control things like circuit breakers
and motors, got updated to use the internet better. This allowed different parts of a
SCADA system to talk to each other more smoothly over the internet.

Tunneling Legacy SCADA over IP Networks
In modern networks, connecting old industrial systems like DNP3 and SCADA to
the internet can be tricky because they were made before the internet was common.
Ideally, they should work directly with the internet, but sometimes they need help.
(below paragraph strictly for your understanding)
Think of it like translating a language - sometimes you need someone to help you
understand what others are saying. This help can come in different forms, like
putting the old system's messages inside internet messages
(like putting a letter in an envelope) or using a special device to translate between
the old system and the internet.

Additional Example reference:-
Imagine you have a bunch of gadgets (RTUs) scattered around your house, like
sensors and smart switches. These gadgets talk to a main computer (SCADA
server) that controls them. But instead of chatting directly, they use special wires
(serial connections) hooked up to routers. So, the routers act like messengers,
carrying messages between the gadgets and the main computer
In Scenario A imagine each gadget (RTU) and the main computer (SCADA server)
have a direct wire connecting them to a router.
These routers act as gateways, taking the messages from the gadgets and sending
them over the internet to the main computer. They wrap up the messages in a special
way (raw socket encapsulation) so they can travel smoothly over the internet.
(It's like each gadget is sending a letter through a special envelope made for internet
travel, and the router is the postman making sure it gets to the main computer.)

Scenario B has a small change on the SCADA server side. A piece of software is
installed on the SCADA server that maps the serial COM ports to IP ports. This
software is commonly referred to as an IP/serial redirector.
In Scenario C, think of the SCADA server as a super-smart computer that can
directly connect to other devices without needing any extra help. Unlike before,
where it had to rely on routers or special software to talk to other devices, now it
can do it all on its own. This makes things much simpler and faster because it
doesn't have to go through any middlemen to communicate with other machines.

SCADA Protocol Translation
Protocol translation is like having a language interpreter at work. Imagine two
friends who speak different languages trying to talk. Similarly, in the world of
networking, devices sometimes speak different "languages" too. In this case, an
IOT gateway acts as an interpreter, allowing devices that communicate in serial
(like old-school phone lines) to talk to devices that use IP (like the internet). This
translation happens at the edge of the network, making communication smoother
and more efficient, kind of like having a bilingual friend helping out in a
conversation.

SCADA Transport over LLNs with MAP-T
In simpler terms, imagine you have old gadgets that only understand one language (IPv4)
and a new network that speaks a different language (IPv6). To make them work together,
you need a translator, like MAP-T, that helps them understand each other. This setup
allows your old gadgets, like legacy industrial devices, to communicate with modern
systems over the new network seamlessly. MAP-T acts as a bridge between the two
worlds, ensuring smooth communication despite the differences in languages spoken by
the devices and the network.

Generic web-based protocols
Generic web-based protocols are commonly used in IOT projects due to their
familiarity and ease of integration.
These protocols enable IOT devices to communicate with each other and with
other applications over networks like Ethernet or Wi-Fi.
Devices can either act as clients, pushing data to applications, or host server-
side services for incoming connections, depending on their functions and resource
constraints.
As collaborative applications integrating real-time communication tools with
IOT devices become more prevalent, simpler communication systems like XMPP
are needed to facilitate interactions between people and devices in real-time.

CoAP and MQTT are naturally at the top of this sample IoT stack, based on an
IEEE 802.15.4 mesh network. While there are a few exceptions, like CoAP
deployed over UDP and MQTT running over TCP.
High-Level IOT Protocol Stack for CoAP and MQTT

CoAP(Constrained Application Protocol)
CoAP is a set of rules made by a RFC to help tiny gadgets talk to each other on the
internet.
It's made specially for devices like sensors and gadgets that don't have a lot of
power or memory.
Think of it like a secret language that these gadgets use to send messages to each
other really quickly and safely.
There are different rules called standards that explain how CoAP works, like how
to keep messages secure and how to make sure they get to the right place.
It's like having a special code for sending secret messages between gadgets!

The CoAP framework defines simple and flexible ways to manipulate sensors and
actuators for data or device management .The IETF CoRE working group has
published multiple standards-track specifications for CoAP, including the
following:
• RFC 6690: Constrained RESTful Environments (CoRE) Link Format
• RFC 7252: The Constrained Application Protocol (CoAP)
• RFC 7641: Observing Resources in the Constrained Application Protocol
(CoAP)
• RFC 7959: Block-Wise Transfers in the Constrained Application Protocol
(CoAP)
• RFC8075: Guidelines for Mapping Implementations: HTTP to theConstrained
Application Protocol (CoAP)

CoAP, a special internet language for small gadgets, can work on both IPv4 and
IPv6 networks. It's best if the messages it sends can fit into one package without
getting broken up. For IPv6 networks, the message can be a bit bigger, up to 1152
bytes, while for IPv4, it's safer to keep it smaller. Even though most messages sent
by gadgets are small, CoAP has a way (RFC 7959) to handle big ones, like when
updating gadget software. In the internet world, gadgets using CoAP can talk to
each other directly or through a middleman called a proxy, even if they're on
different types of networks.

MQTT, or Message Queuing Telemetry Transport
It is a lightweight messaging protocol designed for efficient communication
between devices in environments with limited resources and unreliable networks.
It operates on top of the TCP/IP protocol and follows a publish/subscribe model,
allowing devices to publish messages to topics and subscribe to receive messages
from specific topics.
MQTT is commonly used in IOT (Internet of Things) applications for its
simplicity, low bandwidth usage, and support for intermittent connections.

In the late 1990s, IBM and Eurotech engineers sought a reliable and lightweight
protocol to manage numerous sensors and their data from a central server,
particularly for industries like oil and gas.
Their efforts led to the creation of MQTT, now standardized by OASIS, tailored
for challenging environments with limited resources and unreliable networks.
MQTT's design prioritized simplicity, with a focus on constrained nodes and
variable network conditions, adopting a client/server and publish/subscribe
approach over TCP/IP.

(STRICTLYT FOR YOUR REFERENCE)
Imagine MQTT as a way for devices, like your smartphone or a temperature
sensor, to chat with each other. In this chat system, devices can either be talkers
or listeners. For example, a sensor might be a talker, sending its temperature
readings to a central hub, which acts like a chat room where all the data goes.
Then, other devices, like your computer or another sensor, can listen in and get
that temperature info.
The cool thing is, devices don't need to know about each other directly; they just
send their messages to the central hub, and the hub makes sure everyone who
needs the info gets it. This system uses the internet to send messages, and it's
pretty smart because even if a device isn't online at the same time as the others, it
can still get the info later when it's back online. Plus, it's safe and secure because
it uses special codes to keep the messages private.

In MQTT, "QoS" stands for "Quality of Service." It refers to the level of guarantee
that is provided regarding message delivery between MQTT clients and brokers.
MQTT supports three levels of QoS:
1. QoS 0 (At most once): The message is delivered at most once or not at all.
There is no acknowledgment from the receiver, and the message is sent without
any delivery guarantee.
2. QoS 1 (At least once): The message is guaranteed to be delivered at least once
to the receiver. If necessary, the message can be resent until acknowledgment of
receipt is received from the receiver.
3. QoS 2 (Exactly once): The message is guaranteed to be delivered exactly once
to the receiver. This level of QoS ensures that duplicate messages are not delivered
even in the presence of network disruptions or other issues.
The choice of QoS level depends on the application requirements and the desired
level of reliability for message delivery.

IOT_MODULE_3.pdf simple example notes for use

More Related Content

Similar to IOT_MODULE_3.pdf simple example notes for use (20)

Recently uploaded (20)

IOT_MODULE_3.pdf simple example notes for use