IoT- Module-4, ENGINEERING IOT NETWORKS.

Module-4
ENGINEERING IOT NETWORKS
IP as IoT network layer, Key Advantages, Adoption, Optimization,
Constrained Nodes, Constrained Networks, IP versions, Optimizing IP for
IoT. (Ch-5)
Application Protocols for IoT – Transport Layer, Application Transport
layer, Background only of SCADA, Generic web-based protocols, IoT
Application Layer (Ch 6)
Data and Analytics for IoT – Introduction, Structured and Unstructured
data, IoT Data Analytics Overview and Challenges.(Ch 7)
RBT Level: L1, L2, L3

IoT devices are connected devices that generate large amounts
of data, including sensor data, location data, and device usage
data. This data can be used to improve operational efficiency,
better resource utilization, lower maintenance and labor costs,
and greater customer satisfaction and loyalty.

Ip As Iot Network Layer
ENGINEERING IOT NETWORKS
-Ch5

“IP as IoT network layer" refers to the use of Internet Protocol (IP) as the
foundational networking layer for connecting and communicating between IoT
devices.
The Internet Protocol is a set of rules that govern how data is sent and received
over the internet.
IP provides a standardized way for devices to communicate with each other,
enabling seamless connectivity across diverse networks.

This chapter includes..
1. The Business Case for IP
2. The Need for Optimization
3. Optimizing IP for IoT
4. Profiles and Compliances

The Business Case for IP
➢Data flowing from or to “things” is consumed, controlled, or
monitored by data center servers either in the cloud or in locations that
may be distributed or centralized.
➢Dedicated applications are then run over virtualized or traditional
operating systems or on network edge platforms.
➢These lightweight applications communicate with the data center
servers.

Therefore, the system solutions combining various physical and
data link layers call for an architectural approach with a common
layer(s) independent from the lower (connectivity) and/or upper
(application) layers.
This is how and why the Internet Protocol (IP) suite started playing
a key architectural role in the early 1990s.

The Key Advantages Of Internet Protocol

One of the main differences between traditional information technology
(IT) and operational technology (OT) is the lifetime of the underlying
technologies and products.
One way to guarantee multi-year lifetimes is to define a layered
architecture such as the 30-year-old IP architecture.
IP has largely demonstrated its ability to integrate small and large
evolutions.

1. Open and standards-based: (IETF) standard.
2. Versatile
3. Ubiquitous
4. Scalable
5. Manageable and highly secure
6. Stable and resilient
7. Consumers’ market adoption
8. The innovation factor

1. Open and standards-based
Companies often give ready-to-use operational tools with special
communication methods that they keep private.
The Internet of Things allows devices, apps, and users to use many
features together, ensuring they can work well together, stay secure,
and be easily managed.
This calls for the implementation, validation, and deployment of
open, standards-based solutions.
Rukmini B,

2. Versatile
A large spectrum of access technologies is available to
offer connectivity of things in the last mile.
Additional protocols and technologies are also used to
transport IoT data through backhaul links and in the data
center.

3. Ubiquitous
Most modern operating systems, whether for regular computers or
smaller embedded systems (TinyOS, Contiki), include a dual IP
stack (IPv4 and IPv6) that improves over time.
IoT application protocols in many industrial OT solutions have
been updated in recent years to run over IP.
IP is the most widely used and common protocol in different IoT
solutions and industries(Verticals).

4. Scalable
As the standard internet protocol, IP has been extensively used
and proven to be highly scalable and robust.
Certainly, incorporating a large number of "things" into both
private and public systems may need special optimizations and
design guidelines tailored to these new devices.

5. Manageable and highly secure
Communications infrastructure requires appropriate
management and security capabilities for proper
operations.
Popular network and security management tools
seamlessly integrate with an IP network layer..

6. Stable and Resilient
IP has a strong foundation of knowledge and has been employed for years in
crucial infrastructures like finance and defense networks.
The stability and strength of IP benefit from a large community of IT experts
who can assist in creating, implementing, and managing IP-based solutions.

7. Consumer’s Market Adoption
When creating IoT products for consumers, vendors understand that
people will mostly access applications and devices through
broadband and mobile wireless connections.
IP is the underlying protocol for applications ranging from file
transfer and e-mail to the World Wide Web, e-commerce, social
networking, mobility, and more.

8. The innovation factor
The past two decades have largely established the adoption of IP
as a factor for increased innovation.
IP is a standards-based protocol that is ubiquitous, scalable,
versatile, and stable. Network services such as naming, time
distribution, traffic prioritization, isolation, and so on are well
known and developed techniques that can be leveraged with IP.

Adoption Or Adaptation Of The
Internet Protocol

Using Internet Protocol (IP) in data centers and the cloud for IoT is
common, but making the final connection to end devices with IP can be
tricky, causing challenges for a seamless connection.
Routers capable of handling multiple protocols became necessary to
manage the growing variety of network layer protocols.
The use of numerous network layer protocols in addition to IP is often a
point of contention between computer networking experts.

Typically, one of two models, adaptation or adoption, is proposed:
➢ Adaptation means application layered gateways (ALGs) must be
implemented to ensure the translation between non-IP and IP layers.
➢ Adoption involves replacing all non-IP layers with their IP layer
counterparts, simplifying the deployment model and operations.

IP Adaptation and Adoption applied to IoT last mile connectivity
Industries are shifting to use IP in manufacturing, but with product cycles
lasting over 10 years, various protocols for serial communications have
emerged.
Recent versions of serial communication protocols now include support for
Ethernet and IPv4, even though they were not initially specified.

Supervisory control and data acquisition (SCADA) applications are
typical examples of vertical market deployments that operate both the IP
adaptation model and the adoption model.
With the IP adoption model, SCADA devices are attached via Ethernet to
switches and routers forwarding their IPv4 traffic.
Another example is a ZigBee solution that runs a non-IP stack between
devices and a ZigBee gateway that forwards traffic to an application server.

The following factors has to be taken into consideration to determine which
model is best suited for the last-mile connectivity:
1. Bidirectional versus unidirectional data flow
While bidirectional communications are generally expected, some last-mile
technologies offer optimization for unidirectional communication.
For ex : different classes of IoT devices, as defined in RFC 7228.
If communication is only one-way for uploading data to an application, it's
not possible to download new software or firmware to the devices.

2. Overhead for last-mile communications paths
IP adoption implies a layered architecture with a per-packet overhead that
varies depending on the IP version.
If a device sends data infrequently and in small amounts, the header overhead
might be more than the actual device data.
Hence We must determine if adopting the IP model is needed and, if so, figure
out how to make it more efficient/Optimized.

3. Data flow model
One benefit of the IP adoption model is the end-to-end nature of
communications.
Nodes in a network can exchange data easily, but factors like security and
privacy may impose controls on the "end-to-end" concept.
In many IoT solutions, a device's data flow is limited to one or two
applications.
This allows the adaptation model to work efficiently, focusing on traffic
translation solely between the end device and those specific application
servers.

4. Network Diversity
One of the drawbacks of the adaptation model is a general
dependency on single PHY and MAC layers.
For example, ZigBee devices must only be deployed in
ZigBee network islands. This same restriction holds for ITU
G.9903 G3-PLC nodes.
Therefore, a deployment needs to consider which applications
should run on the gateway connecting these islands to the rest of
the world.

Building IoT solutions on IP poses numerous challenges.
Dealing with the integration of non-IP devices and
addressing limits at both device and network levels is
necessary in IoT.
Therefore, optimizations are needed at various layers of
the IP stack to handle the restrictions that are present in
IoT networks.

Why optimization is necessary in IP based IoT solutions:
➢ IoT is a platform, where different classes of devices coexist.

A "thing" architecture may or may not share similar characteristics with a
generic PC or server in an IT environment, depending on its network
functions.
Another limit is that this network protocol stack on an IoT node may be
required to communicate through an unreliable path.
Even if a full IP stack is available on the node, this causes problems such as
limited or unpredictable throughput and low convergence when a topology
change occurs.
Power consumption is vital for constrained nodes, as IoT devices, often
battery-powered, can have lifetimes ranging from months to over 10 years.

IoT constrained nodes can be classified as follows:

Devices that are very constrained in resources, may communicate infrequently
to transmit a few bytes, and may have limited security and management
capabilities
➢ This drives the need for the IP adaptation model, where nodes communicate
through gateways and proxies.
Devices with enough power and capacities to implement a stripped-down IP
stack or non-IP stack
➢ They can either use an optimized IP stack for direct communication with
application servers (adoption model) or opt for an IP or non-IP stack with
gateways and proxies (adaptation model).
Devices that are similar to generic PCs in terms of computing and power
resources but have constrained networking capacities, such as bandwidth
➢ Nodes typically have a full IP stack (adoption model), but network design and
applications need to handle bandwidth constraints.

Constrained networks, known as low-power and lossy networks (LLNs), are
termed "lossy" due to disruptions in data flow or packet loss causing network
unreliability.
Constrained networks, unlike typical IP networks with stable and fast links, are
restricted by low-power, low-bandwidth links, both wired and wireless.
Unstable link layer environments create challenges related to latency and
control plane.
Control plane traffic must also be kept at a minimum; otherwise, it consumes
the bandwidth that is needed by the data traffic.

In IoT, both IPv4 (lack of address space) and IPv6 (larger range of addresses)
versions of the Internet Protocol are commonly used to enable communication
between devices and ensure connectivity within the Internet of Things
ecosystem.
Techniques such as tunneling and translation need to be employed in IoT
solutions to ensure interoperability between IPv4 and IPv6.
The main factors applicable to IPv4 and IPv6 support in an IoT solution:
➢ Application Protocol
➢ Cellular Provider and Technology
➢ Serial Communications
➢ IPv6 Adaptation Layer

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.
➢ SCADA protocols like DNP3/IP (IEEE 1815), Modbus TCP, and IEC
60870-5-104 are exclusively designed for IPv4.
➢ Currently, vendors have not implemented these protocols over IPv6 in
production.
➢ IoT devices using IETF-defined application protocols like HTTP/HTTPS,
CoAP, MQTT, and XMPP support both IP versions.
The selection of the IP version is only dependent on the implementation.

Cellular Provider and Technology:
IoT devices with cellular modems rely on both the cellular technology
generation and the data services provided by the carrier.
➢ For GPRS, Edge, and 3G data services, IPv4 serves as the foundational
protocol version
➢ Consequently, IPv6 requires tunneling over IPv4
➢ On 4G/LTE networks, data services can use IPv4 or IPv6 as a base
protocol, depending on the provider.

Serial Communications:
➢ Data is sent using protocols like DNP3, Modbus, or IEC 60870-5-101.
Previously reliant on analog modems, serial data communication now uses
local connections due to the decline of analog services.
➢ Legacy devices connect their serial ports to nearby routers, forwarding data
over IP to the central server.
➢ Encapsulation of serial protocols over IP, mainly supporting IPv4 in current
implementations, utilizes mechanisms like raw socket TCP or UDP.

IPv6 Adaptation Layer:
➢ Some IoT protocols only support IPv6 for specific physical and data link
layers. Common layers like Ethernet and Wi-Fi work with both IPv4 and
IPv6.
➢ However, newer technologies like IEEE 802.15.4, IEEE 1901.2, and ITU
G.9903 use only IPv6.
➢ Therefore, devices using these technologies must communicate solely
over an IPv6 subnetwork.
➢ The IETF routing protocol for LLNs, RPL, also follows this by being IPv6
only.

Optimizing IP is
essential for successful
IoT, especially in
constrained nodes and
networks, requiring
optimization across
layers and protocols
Figure 5.1 highlights
the TCP/IP layers where
optimization is applied.

APPLICATION PROTOCOLS FOR IOT
–(Ch 6)

This chapter explores the transport of higher-layer IoT protocols.
The Transport Layer
In IoT networks, constrained resources necessitate a re-evaluation of
traditional TCP and UDP transport mechanisms.
IoT Application Transport Methods
This section discusses different types of IoT application, data and how
it can be transmitted over a network.

This section examines the choice of a transport layer protocol within the
TCP/IP architecture for IoT networks, focusing on two main protocols.
1. Transmission Control Protocol (TCP):
➢ This protocol, similar to a phone call, needs a connection to be set up
between the sender and receiver before data exchange, much like
establishing a conversation on a traditional telephone.
2. User Datagram Protocol (UDP):
➢ This protocol allows fast data transmission between source and
destination, but there's no assurance of delivery, similar to mailing a
letter where confirmation occurs only when a response letter is sent.

TCP is commonly used in Internet interactions for its capacity to handle large data volumes
with features like re-assembly, flow control, and re-transmission.
TCP's overhead affects packet performance and latency.
UDP is preferred for real-time data traffic and specific network services, emphasizing
performance and latency over re-transmissions.
The choice between TCP and UDP in IoT applications should weigh impacts on both lower
and upper layers of the network stack.
Industrial protocols often utilize TCP for reliability, considering historical deployment in
less reliable data link layers.
However, TCP can be impractical for constrained IoT devices due to overhead, especially
when transmitting minimal data.

➢ IoT nodes encounter TCP challenges in low-power and lossy networks
(LLNs) due to data link layer constraints.
➢ New protocols like CoAP prefer UDP to handle issues with numerous
TCP sessions.
➢ Industrial protocols, e.g., DLMS/COSEM, may optimize for LLNs by
adapting to UDP.
➢ IoT transport protocols at lower layers impact adjustments in application
layer protocols.
➢ DLMS/COSEM transport comparison highlights the influence of lower-
layer protocols on application layer adaptations.

When comparing the transport of DLMS/COSEM over a cellular network
versus an LLN deployment, consider the following factors.
➢ TCP is recommended for cellular networks due to their robust nature, while
UDP is preferable and often mandatory for constrained LLNs.
➢ DLMS/COSEM reduces LLN overhead with a "long association"
minimizing communication overhead, while in cellular networks, a short
association is preferred to control costs by swiftly closing connections after
transmission.
➢ DLMS/COSEM efficiently transfers large data over cellular links and
handles smaller data effectively in LLNs, reducing retransmissions due to
higher packet loss ratios compared to cellular networks.

TCP and UDP are the main transport layer choices in TCP/IP, and the
selection between them impacts the performance and scalability of IoT
constrained devices and networks.

IoT Application Transport Methods

IoT application protocols, ranging from legacy industrial to
modern ones, have diverse transport needs.
Simplifying decisions involves categorizing and exploring
transport methods for each category.

The following are categories of IoT application protocols and their transport methods
Application layer protocol not present:
➢Data payload is directly transported on top of the lower layers.
Supervisory control and data acquisition (SCADA):
➢SCADA has been adapted for IP networks.
Generic web-based protocols:
➢IoT devices commonly use Ethernet, Wi-Fi, and 4G/LTE on non-constrained networks.
IoT application layer protocols:
➢ MQTT and CoAP, IoT protocols, cater to constrained nodes, managing compute
resources and bandwidth on cellular, satellite, or 6LoWPAN networks.

Application Layer Protocol Not Present
Class 0 send or receive only a few bytes of data.
➢ Class 0 devices skip a full network protocol stack, including IP, TCP, UDP, or an
application layer protocol, due to processing power, power constraints, and cost.
➢ These simple smart objects face severe constraints, making a robust protocol stack
impractical or impossible with limited resources.
Many constrained devices, like sensors and actuators, lack a standardized application layer
in their deployments.
➢ Non-standardization hampers the success of generic implementations for this transport
method in terms of interoperability.
➢ For example, temperature sensors from different manufacturers may report data in
varied formats.

An IoT data broker, acting as middleware, standardizes sensor output for
authorized applications.
In the figure 6.1, temperature sensors X, Y, and Z employ different encoding.
The data broker decodes diverse formats into a common one, allowing
Applications A, B, and C to access temperature data without managing multiple
formats.
The solution to this problem is to use an IoT data broker

SCADA, initially designed decades ago, was implemented without IP over
serial links (e.g., RS-232 and RS-485) and later adapted to Ethernet and
IPv4.
➢ SCADA protocols operate directly over serial layers, collecting sensor
data for real-time remote device control.
➢ They use specific protocols like Modbus for industrial applications and
others (DNP3, IEC, DLMS/COSEM, ANSI C12) in utilities and meter
reading.
➢ Dating back decades, these serial-based protocols need adjustments for
transport over current IoT and traditional networks.

Ethernet and IP seamlessly integrate SCADA subnetworks into corporate
WANs, utilizing existing equipment and standards.
Protocol assignments for TCP/UDP are as follows:
➢ DNP3 (adopted by IEEE 1815-2012) uses TCP or UDP, Modbus uses TCP,
IEC 60870-5-104 evolves from IEC 60870-5-101 for Ethernet and IPv4 on
port 2404, and DLMS User Association specifies a TCP/IP-based
communication profile in DLMS/COSEM.
Adapting SCADA for IP

Programmers who know web protocols well can contribute to IoT projects,
opening the door to creative approaches for handling real-time data.
In networks like Ethernet, Wi-Fi, or 3G/4G, where bandwidth is not a
problem, detailed data models can be used for information transfer.
For constrained networks, advanced embedded web servers with minimal
memory (around 10KB) are now in use to optimize performance.
IoT devices that send data to applications might require web services on
their side. For instance, a weather station using Ethernet or Wi-Fi to
share data with a weather map app.

HTTP client side starts connections but doesn't accept incoming ones.
Other devices, like video cameras, may have web services on the server side.
Communication tools, like voice and video apps, chat rooms, and IoT
devices, are connecting in real-time. They use protocols like XMPP
(Extensible Messaging and Presence Protocol).
For limited networks or many small devices, using detailed web protocols
might be too much for IoT applications.
To solve this, there are new lightweight protocols designed for lots of small
nodes and networks.
Two common ones are CoAP and MQTT.

CoAP MQTT
UDP TCP
IPv6
6LoWPAN
802.15.4 MAC
802.15.4 PHY
Figure 6-6 Example of a High-Level IoT
Protocol Stack for CoAP and MQTT
CoAP and MQTT lead
in this IoT stack, built
on an IEEE 802.15.4
mesh network.
CoAP deployed over
UDP and MQTT
running over TCP.

IoT Application Layer
IoT Application Layer Protocols

CoAP
❖ CoAP (Constrained Application Protocol) is an IoT application layer
protocol.
❖ Designed for constrained devices, CoAP operates over UDP for low-power
and low-bandwidth networks.
❖ It simplifies communication, providing a RESTful interface for resource-
constrained devices.
❖ CoAP supports request-response interactions, facilitating efficient data
exchange in IoT applications.
❖ Key features include multicast support, stateless operation, and lightweight
header design.
❖ It is widely used for applications where constrained devices require
efficient and reliable communication in IoT ecosystems.

Constrained Application Protocol (CoAP)
The goal is to create a framework for simple applications on small devices and
networks.
CoAP helps manage sensors and devices easily.
CoAP uses UDP for message exchange between endpoints, with added security
through DTLS.
For IoT device management, CoAP over SMS follows the Open Mobile
Alliance's Lightweight Machine-to-Machine (LWM2M) standards.

A CoAP message has a short
4-byte Header field.
It includes a mandatory
Token field of variable
length (0–8 bytes).
Options fields are included
if needed, along with the
Payload field.

CoAP Message
Field
Description
Ver (Version) Identifies the CoAP version.
T (Type) Defines four message types: Confirmable (CON), Non-confirmable (NON),
Acknowledgement (ACK), or Reset (RST), with specific details on CON and
ACK.
TKL (Token
Length)
Specifies the size (0–8 Bytes) of the Token field.
Code Indicates the request method and response code in messages. Ex., GET is the
method, and 2.05 is the response code.
Message ID Detects message duplication and matches ACK and RST to CON and NON
message types.
Token With a length specified by TKL, correlates requests and responses.
Options Specifies option number, length, and value, providing capabilities like defining
the target resource and proxy functions.
Payload Holds optional CoAP application data. If included, a single byte of all 1s (0xFF)
signals the end of Options and the start of Payload.

CoAP can run over IPv4 or IPv6. However, it is recommended that the message
fit within a single IP packet and UDP payload to avoid fragmentation

CoAP in IoT allows communication between devices on the same or different
networks, including the Internet or cloud servers, all using IP.
The proxy function in CoAP, similar to HTTP, can be placed anywhere in the
network, not just at the border between constrained and non-constrained networks.
CoAP, like HTTP, adheres to the REST architecture, but with a "thing" serving as
both the client and the server.
Using asynchronous messages, a client asks a server to perform an action on a
resource using a method code.
The server identifies the resource using a URI on the server and responds with a
code, possibly containing a resource representation.
CoAP request/response follows methods like GET, POST, PUT, and DELETE.

MQTT
❖ MQTT (Message Queuing Telemetry Transport) is a widely used IoT application layer
protocol.
❖ Designed for efficient communication in low-bandwidth, high-latency, or unreliable
networks.
❖ Follows a publish/subscribe model, allowing devices to publish data to topics and
subscribe to receive specific information.
❖ Uses a lightweight header, minimizing overhead and making it suitable for resource-
constrained devices.
❖ Supports Quality of Service (QoS) levels for message delivery reliability.
❖ Ideal for scenarios where real-time data exchange and low energy consumption are
crucial, such as in smart homes and industrial IoT applications.

In the late 1990s, IBM and
Arcom engineers developed
MQTT, a standardized
protocol for cost-effective
sensor monitoring and
control in the oil and gas
industries by OASIS.
The protocol for oil and gas
environments handles
constraints using a TCP/IP-
based client/server and
publish/subscribe framework
(Figure 6-10).
Message Queuing Telemetry Transport (MQTT)

➢ An MQTT client acts as a publisher, sending data to a server.
➢ On the left, a sensor publishes temperature and humidity (Temp/RH) data.
➢ The MQTT server accepts connections and manages subscriptions.
➢ It sends data to MQTT clients on the right, acting as subscribers.
➢ One client on the right subscribes to Temp/RH data from the left sensor.
➢ This familiar model involves subscribers actively seeking information from
publishers.

➢ MQTT's message broker decouples data transmission between publishers
and subscribers.
➢ Publishers and subscribers don't need to know about each other.
➢ Decoupling in MQTT ensures that the message broker can buffer and
cache information during network failures.
MQTT contains a smaller header of 2 bytes compared to 4 bytes for CoAP.

➢ MQTT is lightweight with a 2-byte fixed header, optional variable fields,
and payload.
➢ The header's first field, Message Type, identifies the packet's kind.
➢ Fourteen control packet types are specified in MQTT, each with a unique
value in the Message Type field.

Table 6-2 MQTT Message Types
Message Type Value Flow Description
CONNECT 1 Client to server Request to connect
CONNACK 2 Server to client Connect acknowledgement
PUBLISH 3 Client to server
Server to client
Publish message
PUBACK 4 Client to server
Server to client
Publish acknowledgement
PUBREC 5 Client to server
Server to client
Publish received
PUBREL 6 Client to server
Server to client
Publish release
PUBCOMP 7 Client to server
Server to client
Publish complete

Message Type Value Flow Description
SUBSCRIBE 8 Client to server Subscribe request
SUBACK 9 Server to client Subscribe acknowledgement
UNSUBSCRIB
E
10 Client to server Unsubscribe request
UNSUBACK 11 Server to client Unsubscribe acknowledgement
PINGREQ 12 Client to server Ping request
PINGRESP 13 Server to client Ping Response
DISCONNECT 14 Client to server
Server to client
Client disconnecting

➢ MQTT's DUP flag notes if a packet was sent without acknowledgment.
➢ QoS offers three levels for message delivery customization.
➢ The Retain flag, in PUBLISH messages, tells the server to keep message
data, benefiting new subscribers.
➢ This ensures instant access to the last known value, skipping the wait for
the next update.
➢ The last MQTT header field, Remaining Length, indicates the following
packet's byte count.

➢ MQTT sessions include establishment, authentication, data exchange,
and termination phases.
➢ Unique client IDs identify sessions between clients and servers.
➢ When sending messages to multiple clients, the server treats each
independently.
➢ SUBSCRIBE/SUBACK handles subscriptions, and
UNSUBSCRIBE/UNSUBACK manages unsubscriptions.
➢ DISCONNECT packet allows graceful connection termination and
permits client reconnection by resending their ID.

Data and Analytics for IoT
-Ch 7

An Introduction to Data Analytics for IoT:
Modern jet engines are fitted with thousands of sensors that generate a
whopping 10GB of data persecond.
Modern jet engines, may be equipped with a round 5000 sensors.
A twin engine commercial aircraft with these engines operating on
average 8 hours a day will generate over 500 TB of data daily, and this is
just the data from the engines!
Aircraft today have thousands of other sensors connected to the
airframe and other systems. A single wing of a modern jumbo jet is
equipped with 10,000 sensors.

Structured data and
unstructured data are
important classifications as
they typically require
different tool sets from a
data analytics perspective.
Figure provides a high-level
comparison of structured
data and unstructured data.
Structured Versus Unstructured Data:

IoT- Module-4, ENGINEERING IOT NETWORKS.

IoT- Module-4, ENGINEERING IOT NETWORKS.

More Related Content

What's hot

Similar to IoT- Module-4, ENGINEERING IOT NETWORKS.

More from T.D. Shashikala

Recently uploaded

IoT- Module-4, ENGINEERING IOT NETWORKS.