Unit IV

Network and Communication

Aspects
Dr. Prabhakar D. Khandait
HOD (ETC)
KDKCE, Nagpur
 IoT
Unit IV: Network and Communication Aspects (05)

• Wireless medium access issues,

• MAC protocol,
• Survey routing protocols,
• Sensor deployment & Node discovery,
• Data aggregation & dissemination,
• service model,
• service management and security.
 Wireless medium access issues

• The Internet of Things (IoT) refers to the interconnection of physical

devices, vehicles, buildings, and other items embedded with
electronics, software, sensors, and network connectivity.
• One of the challenges with IoT devices is how they access the wireless
medium.
• Here are some issues related to wireless medium access in IoT:
• Interference: With the proliferation of IoT devices, there are concerns
about the coexistence of various wireless technologies. Interference
can arise when multiple IoT devices are trying to communicate over
the same wireless channel, leading to data loss and delays.
 Wireless medium access issues….
• Limited bandwidth: IoT devices often have limited processing and
communication capabilities, leading to low data rates.
• This can cause a bottleneck when multiple devices are trying to access the
wireless medium simultaneously.
• Energy consumption: Many IoT devices are battery-powered and have
limited energy resources. Transmitting and receiving data wirelessly
consumes a significant amount of energy, and as such, IoT devices need to
conserve energy to extend their battery life.
• Security: IoT devices are often deployed in uncontrolled environments,
making them vulnerable to security breaches.
• Wireless medium access needs to be secure to protect sensitive data from
being intercepted by unauthorized parties.
• Scalability: With the increasing number of IoT devices being deployed,
there is a need for a wireless medium access scheme that can scale to
accommodate the increasing demand for connectivity.
 Wireless medium access issues….
• To address these issues, various wireless medium access protocols
have been developed for IoT devices, such as Zigbee, Wi-Fi, and
Bluetooth.
• These protocols have different features and are optimized for specific
use cases, and selecting the appropriate protocol depends on the
specific requirements of the application.
 MAC protocol
• Medium access control or media access control (MAC)
protocol enforce a methodology to allow multiple devices access to a
shared media network.
• Before LANs, communication between computing devices had been
point-to-point. That is, two devices were connected by a dedicated
channel.
• In computer networking, the Medium Access Control (MAC) protocol
is a set of rules that govern how devices on a shared communication
network access the medium for transmitting data.
 MAC protocol….
• The MAC protocol is responsible for coordinating access to the
physical layer of the network, ensuring that multiple devices can
communicate with each other without interfering with each other's
transmissions.
• The MAC protocol defines how a device requests permission to
transmit data and how it receives that permission.
• It also includes procedures for resolving conflicts that may arise when
multiple devices attempt to transmit at the same time.
 ISO OSI model

• The Open Systems Interconnection

model (OSI model) is a conceptual
model that 'provides a common basis
for the coordination of [ISO] standards
development for the purpose of
systems interconnection'. In the OSI
reference model, the communications
between a computing system are split
into seven different abstraction layers:
Physical, Data Link, Network, Transport,
Session, Presentation, and Application.
ISO OSI model
 MAC protocol….
• In IEEE 802 LAN/MAN standards, the medium access control (MAC,
also called media access control) sublayer is the layer that controls
the hardware responsible for interaction with the wired, optical or
wireless transmission medium.
• The MAC sublayer and the logical link control (LLC) sublayer together
make up the data link layer.
• The LLC provides flow control and multiplexing for the logical link
(i.e. EtherType, 802.1Q VLAN tag etc), while the MAC provides flow
control and multiplexing for the transmission medium.
 MAC protocol….
• These two sublayers together correspond to layer 2 of the OSI model. For
compatibility reasons, LLC is optional for implementations of IEEE
802.3 (the frames are then "raw"), but compulsory for implementations of
other IEEE 802 physical layer standards.
• Within the hierarchy of the OSI model and IEEE 802 standards, the MAC
sublayer provides a control abstraction of the physical layer such that the
complexities of physical link control are invisible to the LLC and upper
layers of the network stack.
• Thus any LLC sublayer (and higher layers) may be used with any MAC.
• In turn, the medium access control block is formally connected to
the PHY via a media-independent interface. Although the MAC block is
today typically integrated with the PHY within the same device package,
historically any MAC could be used with any PHY, independent of the
transmission medium.
 MAC protocol…..
• There are different types of MAC protocols, including:
• Contention-based MAC protocol: In this type of MAC protocol, devices
contend for access to the medium by transmitting packets when the channel
is free. If two devices transmit at the same time, a collision occurs, and the
devices must wait a random amount of time before trying again. Examples
of contention-based MAC protocols include Carrier Sense Multiple Access
(CSMA) and Carrier Sense Multiple Access with Collision Detection
(CSMA/CD).
• Controlled access MAC protocol: In this type of MAC protocol, devices are
assigned specific time slots for transmitting data. This ensures that each
device has a guaranteed slot for transmitting data, which reduces the
likelihood of collisions. Examples of controlled access MAC protocols
include Time Division Multiple Access (TDMA) and Polling.
 MAC protocol…..
• Hybrid MAC protocol: This is a combination of contention-based and
controlled access MAC protocols, where devices contend for access to
the medium during contention periods and are assigned specific slots
during controlled periods. This allows for efficient use of the medium
while minimizing collisions.
• Overall, the MAC protocol plays a crucial role in managing
communication between devices in a shared network, and selecting the
appropriate protocol depends on the specific requirements of the
application.
 Routing protocols
• Internet Protocol Version 4 (IPv4)
• IPv4 is 32-bit addressing scheme used as TCP/IP host addressing
mechanism. IP addressing enables every host on the TCP/IP network
to be uniquely identifiable.
• IPv4 is a connectionless protocol used for packet switched networks.
It operates on a best effort delivery model, in which neither delivery
is guaranteed, nor proper sequencing or avoidance of duplicate
delivery is assured.
• Internet Protocol Version 4 (IPv4) is the fourth revision of the Internet
Protocol and a widely used protocol in data communication over
different kinds of networks.
 IPv4….

• IPv4 is a connectionless protocol used in packet-switched layer networks,

such as Ethernet. It provides a logical connection between network devices
by providing identification for each device.
• There are many ways to configure IPv4 with all kinds of devices – including
manual and automatic
• configurations – depending on the network type. IPv4 is defined and
specified in IETF publication RFC 791.
• IPv4 uses 32-bit addresses for Ethernet communication in five classes: A, B,
C, D and E.
• Classes A, B and C have a different bit length for addressing the network
host. Class D addresses are reserved for military purposes, while class E
addresses are reserved for future use.
 IPv4….
• IPv4 Datagram Header
• Size of the header is 20 to 60 bytes.
• VERSION: Version of the IP protocol (4 bits), which is 4 for IPv4
• HLEN: IP header length (4 bits), which is the number of 32 bit words
in the header. The minimum value for this field is 5 and the maximum
is 15.
• Type of service: Low Delay, High Throughput, Reliability (8 bits)
• Total Length: Length of header + Data (16 bits), which has a minimum
value 20 bytes and the maximum is 65,535 bytes.
IPv4….
 IPv4 datagram
• Identification: Unique Packet Id for identifying the group of fragments of a
single IP datagram (16 bits)
• Flags: 3 flags of 1 bit each : reserved bit (must be zero), do not fragment
flag, more fragments flag (same order)
• Fragment Offset: Represents the number of Data Bytes ahead of the
particular fragment in the particular Datagram. Specified in terms of
number of 8 bytes, which has the maximum value of 65,528 bytes.
• Time to live: Datagram’s lifetime (8 bits), It prevents the datagram to loop
through the network by restricting the number of Hops taken by a Packet
before delivering to the Destination.
• Protocol: Name of the protocol to which the data is to be passed (8 bits)
• Header Checksum: 16 bits header checksum for checking errors in the
datagram header
• Source IP address: 32 bits IP address of the sender
 IPv4….
• Destination IP address: 32 bits IP address of the receiver
• Option: Optional information such as source route, record route. Used
by the Network administrator to check whether a path is working or
not.
• Due to the presence of options, the size of the datagram header can be
of variable length (20 bytes to 60 bytes).
• IPv4 provides hierarchical addressing scheme which enables it to
divide the network into sub-networks,each with well-defined number
of hosts.
• IP addresses are divided into many categories:
 IP addresses categories of IPv4
• Class A - it uses first octet for network addresses and last three octets
for host addressing
• Class B - it uses first two octets for network addresses and last two
for host addressing
• Class C - it uses first three octets for network addresses and last one
for host addressing
• Class D - it provides flat IP addressing scheme in contrast to
hierarchical structure for above three.
• Class E - It is used as experimental.
 IP addresses categories of IPv4..
• Each of these classes has a valid range of IP addresses. Classes D and
E are reserved for multicast and experimental purposes
respectively. The order of bits in the first octet determines the classes
of IP address.
• Now let’s see the IP address ranges for each of the classes.
• Class A 10.0.0.0 – 10.255.255.255
• Class B 172.16.0.0 – 172.31.255.255
• Class C 192.168.0.0 – 192.168.255.255
 IP addresses categories of IPv4..

• NOTE
We are going to design the subnets with the private IPs, not public
IPs, because if we use public IPs then it may conflict with the public
IPs provided by internet service provider.
 IP addresses categories of IPv4..

• There is a misconception that we use subnet mask 255.255.255.0 with

Class C , 255.255.0.0 with Class B and 255.0.0.0 with Class A but this is not
right; we can use any subnet mask with any class.
• Now let’s see what this subnet mask does to the IP address.
• For example, if the IP address is 192.168.1.20 and subnet Mask
is 255.255.255.0
• Now we need to answer a few questions looking at the subnet mask.
• What is the first IP or network address in this network?
• What is the last IP or broadcast address in this network?
• What is the gateway IP in this network?
 IP addresses categories of IPv4..

• SOLUTION
• By looking at the subnet mask 255.255.255.0 we can see that first 3 octets are full.
• So, the entire IP address range will start from 192.168.1.0 to 192.168.1.255 in this
network.
• What is the first IP or network address in this network?
• First IP is also called network address and will be 192.168.1.0.
• What is the last IP or broadcast address in this network?
• Last IP is called broadcast address and will be 192.168.1.255.
• What is the gateway IP in this network?
• Next IP after First IP is assigned for the gateway and will be 192.168.1.1.
• Thus, the actual usable IP address range would be from 192.168.1.2 to 192.168.1.254 .
• Total Possible IP addresses in the network will be 0-255 = 256 IP addresses.
 IPv4…
• IPv4 also has well-defined address spaces to be used as private
addresses (not routable on internet), and public addresses (provided
by ISPs and are routable on internet).
• Though IP is not reliable one; it provides ‘Best-Effort-Delivery’
mechanism.
 Internet Protocol Version 6 (IPv6)

• IP v6 was developed by Internet Engineering Task Force (IETF) to

deal with the problem of IP v4 exhaustion.
• IP v6 is a 128-bits address having an address space of 2^128, which is
way bigger than IPv4.
• In IPv6 we use Colon-Hexa representation. There are 8 groups and
each group represents 2 Bytes.
• Exhaustion of IPv4 addresses gave birth to a next generation Internet
Protocol version 6. IPv6 addresses its nodes with 128-bit wide address
providing plenty of address space for future to be used on entire planet
or beyond.
 IPv6 ….

In IPv6 representation, have three addressing methods :

Unicast
Multicast
Anycast
 IPv6 ….
1. Unicast Address –
Unicast Address identifies a single network interface. A packet sent to a
unicast address is delivered to the interface identified by that address.
2. Multicast Address –
Multicast Address is used by multiple hosts, called as Group, acquires a
multicast destination address. These hosts need not be geographically
together. If any packet is sent to this multicast address, it will be
distributed to all interfaces corresponding to that multicast address.
3. Anycast Address –
Anycast Address is assigned to a group of interfaces. Any packet sent to
an anycast address will be delivered to only one member interface
(mostly nearest host possible).
Note: Broadcast is not defined in IPv6.
 Types of IPv6 address:
• We have 128 bits in IPv6 address but by looking at the first few bits
we can identify what type of address it is.
 Routing protocols
• Routing is required for reliable data transmission in a WSN mesh
network.
• Routing protocols are distributed and reactive: nodes in the system
start looking for a route only when they have application data to
transmit.
• Ad hoc on-demand distance vector (AODV) and dynamic source
routing (DSR) are frequently used routing algorithms.
 Routing protocols
• RPL (IPv6 Routing Protocol for Low Power and Lossy Networks) was
developed by the The Internet Engineering Task Force (IETF) Routing
over Low Power and Lossy Networks (RoLL) WG.
• They defined Low Power Lossy Networks as those typically
characterized by high data loss rates, low data rates, and general
instability.
• No specific physical or medium access control technologies were
specified, but typical links considered include PLC, IEEE 802.15.4, and
low-power Wi-Fi.
 Charter of ROLL
• Low-power and lossy networks (LLNs) are made up of many
embedded devices with limited power, memory, and processing
resources.
• They are interconnected by a variety of links, such as (IEEE 802.15.4,
Bluetooth, low-power WiFi, wired or other low power PLC (power line
communication) links.
• LLNs are transitioning to an end-to-end IP-based solution to avoid the
problem of non interoperable networks interconnected by protocol
translation gateways and proxies.
 Routing protocols…..

• The logic behind the development of the protocol was founded on the
traffic flow characteristics of such networks, where typical use cases
involve the collection of data from many (for example) sensing points,
nodes towards a sink, or alternatively, flooding information from a
sink to many nodes in the network.
• Thus, the well-known concept of a Directed Acyclic Graph (DAG)
structure was concentrated to a Destination Oriented DAG (DODAG)
for the purposes of initial development.
• The group defined a new ICMPv6 message, with three possible types,
specific for RPL networks.
 Routing protocols…..

• These include a DAG Information Object (DIO), that allows a node to

discover an RPL instance, configuration parameters and parents, a
DAG Information Solicitation (DIS) to allow requests for DIOs from
RPL nodes, and Destination Advertisement Object (DAO), used to
propagate destination information upwards (i.e. towards the root)
along the DODAG (specific RPL details are available in RFC 6550
and related RFCs).
• The Trickle Algorithm, standardized in 2011 (RFC 6206), and well
known in the WSN community, is an important enabler of RPL
message exchange.
 Routing protocols…..

• The routing protocol RPL [2] developed in ROLL is the protocol

chosen by ZigBee TM IP and 6LoWPAN.
• The advantage of RPL is that it is independent of the media and then
it can be the basis of interoperability between PLC and radio sensors.
Interoperability is simply achieved by routing messages from a PLC
node to a wireless node.
 Routing protocols…..
• Figure below shows an illustration of this dual PHY sensor network.
 RPL

• The IETF Routing Over Low-power and Lossy networks (ROLL) Working
Group was formed in 2008 to create an IP level routing protocol
adapted to the requirements of mesh networking for the Internet of
Things: the first version of RPL (Routing Protocol for Low-power and
lossy networks) was finalized in April 2011.
• RPL specifies a routing protocol specially adapted for the needs of
IPv6 communication over “low-power and lossy networks” or LLNs,
supporting peer to peer traffic (point to point), communication from a
central server to multiple nodes on the LLN( point to multipoint
P2MP) and vice versa (multipoint to point MP2P).
• The base RPL specification is optimized only for MP2P traffic (upward
routing or convergecast used, e.g., in metering networks) or P2MP,
and P2P is optimized only through use of additional mechanisms such
as draft-ietf-roll-p2p-rpl.
 RPL…..
• Such LLNs are a constrained environment, which imply specific
requirements explored by the IETF ROLL working group in RFC5867,
RFC5826, RFC5673, and RFC5548.
• RPL has been designed according to these LLN specific requirements
(typically on networks supporting 6LoWPAN), but is not limited to
operation over LLNs.
• Multiple concurrent instances of RPL may operate in a given network,
each RPL instance is characterized by a unique RPLinstanceID. The
following sections describe the behavior of an individual RPL instance.
 RPL…..
• The RPL routing protocol builds one or more destination oriented
direct acyclic graphs (DODAG).
• Each DODAG is a directed graph with no cycles and with a single root
node (see Figure next slide).
• The graph is built according to optimization objectives specified by an
objective function (OF, defined by the OCP field of a DIO DODAG
configuration option).
• The objective function is not specified by RPL itself, but in other
companion documents according to domain-specific requirements
 RPL…..
• for the available network metrics, the OF computes the “rank”
measuring the “distance” between the node and the DODAG root and
also defines the parent node selection policy, for instance an
objective function could seek to minimize the expected packet delay,
while another might want to avoid routing through any battery-
operated node.
• RPL requires bidirectional links. Bidirectional connectivity must be
verified before accepting a router as a parent, for example, by using
IPv6 neighbor unreachability detection(NUD), bidirectional
forwarding detection (RFC5881) and hints from lower layers via layer
2 triggers like RFC5184.
• RPL Control Messages
• RPL routers need to exchange information in order to build the
DODAG and populate routing tables.
• RPL defines a new ICMPv6 (RFC 4443) message, type 155, for this
purpose.
• RPL defines the following base objects:
• – The DODAG information solicitation (DIS) message;
• – The DODAG information object (DIO), see Figure next slide;
• – The destination advertisement object (DAO);
• – The DAO Ack object;
• – The consistency check (CC) object, which is used to check secure
message counters and to carry RPL challenges and responses, and is
always carried in a secure RPL message.
 Construction of the DODAG and Upward
Routes
• The DODAG information object (DIO) is used to build the DODAG: it
carries general DODAG configuration parameters and information that
allows listening RPL routers to select a set of DODAG parents. Several
type-length-value encoded options in the same RPL control message may
specify:
• – The address of the sending RPL router, and prefixes that may be used for
IPv6 stateless
• auto configuration (0×08 prefix information option, or PIO). The PIO
contains the same fields as the IPv6 neighbor discovery prefix information
option defined in RFC4861,RFC4862 and RFC3775.
• A 1-bit “L flag” indicates that addresses derived from the prefix can be
considered “on-link”, a 1-bit “A flag” indicates that the prefix can be used
for stateless address auto configuration.
 Construction of the DODAG…..
• Metrics allowing estimation of the cost to reach destinations starting
with each prefix (0×02 metric container option, formatted as specified
in ID. IETF-roll-routing-metrics),
• – One or more prefixes that are reachable by the advertising node
(0×03 routing information option, illustrated in Figure next slide and
containing the same fields as the IPv6 neighbor discovery route
information option defined in RFC4191).
• – Additional DODAG configuration information (0×04 DODAG
information option) such as the values of MaxRankIncrease and
MinHopRankIncrease used to constrain the rank a node can advertise
when reattaching to a DODAG, or the default lifetime of all RPL
routes.
 Construction of the DODAG…..
• RPL nodes send DIOs periodically via link-local multicasts, and
joining nodes may request DIOs from their neighbors by multicasting
ICMPv6 control messages containing a DODAG information
solicitation Object (DIS).
• DIO parameters are explained in Figure slide 28, the DTSN is an 8-bit
unsigned integer number set by the issuer of the message.
• In the storing mode of operation, incrementing the DTSN is a way to
request updated DAO messages from child nodes.
Each DODAG, identified by a unique RPLInstanceID and DODAGID,
is built incrementally from the root to leaf nodes:

• – RPL nodes, starting by the DODAG root, advertise their presence,

affiliation with a DODAG, routing cost, and related metrics by sending
link-local multicast DIO messages to the all-RPL-nodes address.
• The DODAG root advertises predefined rank ROOT_RANK
(=MinHopRankIncrease), and also specifies if it is “grounded”, that is,
if it can reach the set of destinations specified by the local DODAG
policy (the “goal”). A DODAG is said to be floating if it cannot satisfy
the goal.
• Nodes use the received DIO information to join a new DODAG and
select their parents in the DODAG, or to maintain their affiliation to
an existing DODAG. Nodes select parents according to the policy
specified by the objective function and the rank of their neighbors as
advertised by DIO messages. For the determination of parent
relationships, the ranks of potential parent nodes are compared with
a granularity of
• MinHopRankIncrease (specified in the DIO messages), so that parent1
and parent2 will be considered of equal rank if floor(rank(parent1)/
MinHopRankIncrease ) = floor(rank(parent2)/MinHopRankIncrease).
 Downward Routes, Multicast Membership
• RPL uses destination advertisement object (DAO, Figure next slide)
messages to establish downward routes and to indicate multicast
group membership. DAO messages are not mandatory and are
required only by RPL instances that provide support for point to
multipoint or peer to peer traffic. RPL control messages carrying a
DAO object may also transport a list prefixes announced as reachable
RPL targets or multicast groups (0×05 RPL target option), opaque RPL
target descriptors (0×09 RPL target descriptor option), and transit
information (0×06 transit information option, Figure 12.11) which is
used
• to indicate attributes for a path to one or more destinations, for
instance its lifetime (a
• lifetime of 0×00000000 indicates loss of reachability to a target).
 Packet Routing
• IP packets injected in an RPL network must have a RPL header that
specifies the RPL instance, except when strict source routing is used.
• If some leaf nodes send IP packets without such an RPL header, the
first RPL router is required to add it, and select a default RPL instance.
The RPL specification in itself does not specify the header format, but
points to the ID-ietf-6man-rpl-option that places the RPL information
into an IPv6 hop-by-hop option header.
• The RPL information includes:
– “O”: the down 1-bit flag indicating the intended direction of the packet.
– “R”: the Rank-Error 1-bit flag signaling that a mismatch has occurred during
forwarding between the rank relationship of the sender and receiver, and
the effective direction of the packet.
Such inconsistency, which can happen during the construction of a new
DODAG version of a given RPL instance, is allowed to happen only once. RPL
routers
• will absorb packets that are already “R” flagged in case such rank
inconsistency is
• detected again.
• – “F”: the forwarding error 1-bit flag which indicates the node cannot
forward the packet
• further towards the destination. In storing mode, routers that receive
packets that they cannot route to their intended destination from a
parent will loop back the packet to this parent with the F flag set: this
allows the parent to remove the erroneous DAO routing entry from
its routing table (“DAO insconsistency detection and recovery”).
• – The 8-bit RPLInstanceID.
• – The 16-bit SenderRank, which must be set to zero by the packet
source and then is set to the rank value of the forwarding RPL router.
• RPL Security
• RPL defines three security models:
• – The “unsecured” model does not implement specific security
features at RPL level, however the layer 2 network may implement
some level of security (e.g., a 802.15.4 network key).
• – The “preinstalled” model requires all RPL nodes to be configured
with preprovisioned keys, which they use to code and decode secure
RPL messages. Secure RPL messages have the high order bit of the
code field set (see Figure 12.7).
• – The “authenticated” mode that also uses a preinstalled key, but only
to join the network as a leaf node. The node will need to obtain a key
or a certificate from an authentication authority to join an
authenticated RPLInstance as a router. This last mechanism is not fully
defined yet and will require future companion specifications.
 Sensor deployment & Node discovery

• Sensor deployment and node discovery are two important aspects of

building an IoT system.
• Here are some approaches to sensor deployment and node discovery
in IoT:
• Manual Deployment: In this approach, the sensors are deployed
manually by technicians or field engineers. This involves physically
installing the sensors in the desired location and configuring them to
communicate with the network.
• Node discovery is also performed manually by scanning the network
for new devices and adding them to the network.
 Sensor deployment & Node discovery
• Automated Deployment: In this approach, sensors are deployed
automatically using robots or drones. The sensors are pre-configured
with the network settings and are dropped off in the desired location
by the robot or drone. Node discovery is also automated, with the
sensors automatically joining the network once they are within range.
• Self-Deploying Networks: This approach involves using self-deploying
networks where the sensors are designed to automatically form a
network without any manual intervention. In this approach, the
sensors are equipped with the necessary hardware and software to
identify and connect to other devices in the network.
 Sensor deployment & Node discovery
• Machine Learning-based Deployment: In this approach, machine
learning algorithms are used to optimize the deployment of sensors
based on factors such as signal strength, interference, and coverage.
The algorithms analyze the data from the sensors to determine the
best locations for deploying new sensors and the best routes for
transmitting data.
 Sensor deployment & Node discovery
• Node discovery in IoT typically involves sending discovery messages on the
network and listening for responses.
• The discovery messages can be sent using various protocols, such as the
Simple Network Management Protocol (SNMP), the Constrained
Application Protocol (CoAP), or the Extensible Messaging and Presence
Protocol (XMPP).
• Once a new node is discovered, it is added to the network and configured
for communication.
• Overall, sensor deployment and node discovery are critical components of
building an IoT system, and the approach chosen depends on factors such
as the scale of the deployment, the available resources, and the specific
requirements of the application.
 Data aggregation & dissemination

• In IoT, data aggregation and dissemination refer to the processes of

collecting data from various sensors, processing and analyzing the
data, and sharing it with the relevant stakeholders. Here are some
common approaches to data aggregation and dissemination in IoT:
• Centralized Approach: In this approach, all data is collected from
sensors and sent to a centralized server or cloud-based platform for
processing and analysis. Once processed, the data is disseminated to
the relevant stakeholders, such as system administrators or end-
users, through various communication channels.
 Data aggregation & dissemination…
• Edge Computing Approach: In this approach, the data is processed at
the edge of the network, closer to the sensors. Edge devices, such as
gateways or routers, collect data from the sensors and perform basic
processing tasks, such as filtering or aggregation. The processed data
is then sent to the cloud for further analysis or directly disseminated
to the relevant stakeholders.
• Distributed Approach: In this approach, the data is collected and
processed by a distributed network of nodes, where each node has
some processing capabilities. The nodes collaborate to perform
complex processing tasks, such as machine learning or predictive
analytics, and disseminate the results to the relevant stakeholders.
 Data aggregation & dissemination…
• Event-based Approach: In this approach, the data is processed and
disseminated based on specific events or triggers. For example, a
sensor may send an alert when a certain threshold is exceeded, and
the alert is disseminated to the relevant stakeholders in real-time.
• The choice of the approach depends on factors such as the scale of
the deployment, the latency requirements, and the processing
capabilities of the network. Regardless of the approach, data
aggregation and dissemination typically involve the use of various
protocols, such as the Message Queuing Telemetry Transport (MQTT),
the Advanced Message Queuing Protocol (AMQP), or the Constrained
Application Protocol (CoAP), to ensure efficient and reliable
communication between the devices and the stakeholders.