Cluster-Based Routing Protocol with Static Hub (CRPSH) for WSN-Assisted IoT Networks

Abstract

The Internet of Things (IoT) is an evolving concept that has achieved prominence in the modern era. An autonomous sensor-equipped device is the major component of WSN-assisted IoT infrastructure. These devices intelligently sense the environment, automatically collect the data, and deliver the information to paired devices. However, in WSN-assisted IoT networks, energy depletion and hardware faults might result in device failures. Additionally, this might affect data transmission. A reliable route significantly reduces data retransmissions, which can help in congestion reduction and energy conservation. Generally, the sensor devices are typically deployed densely throughout the WSN-assisted IoT networks. A high number of sensor devices covering a monitoring area might result in duplicate data. The clustering method can be used to overcome this problem. The clustering technique reduces network traffic, whereas the multipath technique ensures path reliability. In CRPSH, we used the clustering technique to reduce the duplicate data. Moreover, the multipath approach can increase the reliability of the proposed protocol. CRPSH is intended to minimize the overhead associated with control packets and extend the network’s lifetime. The complete set of simulations is carried out using the Castalia simulator. The proposed protocol is found to reduce energy consumption and increase the lifetime of IoT infrastructure networks.

1. Introduction

In a multihop scenario, the sensor device transfers the data to the IoT hub via intermediary sensor devices. WSN-assisted IoT networks are energy constraint networks. So, energy-efficient routing methods are necessary for WSN-assisted IoT networks operating in an energy-constrained environment. However, in WSN-assisted IoT networks, energy depletion and hardware faults might result in device failures. Additionally, this might affect data transmission. A reliable route significantly reduces data retransmissions, which can help in congestion reduction and energy conservation. Generally, the sensor devices are typically deployed densely throughout the WSN-assisted IoT networks. A high number of sensor devices covering a monitoring area might result in duplicate data. The clustering method can be used to overcome this problem. The Cluster Heads (CH) collect data from Cluster Members (CM) prior to sending them to the hub. The clustering technique reduces network traffic, whereas the path reliability is ensured by the multipath technique. These two approaches encourage the development of a hybrid technique that incorporates the benefits of both strategies [1,2].

Devices in WSN-assisted IoT networks must hunt for a way up to the IoT hub for data transmission [3]. Although the device’s technical capabilities are improving all the time, the device’s battery capacity is not keeping up [4]. IoT gadgets use nonrechargeable limited-power batteries. It is also challenging to replace their battery while the devices are in use. Moreover, we need advanced power-saving schemes to make these IoT technologies more adaptable. Due to the energy constraints and limited memory capacity of these IoT devices, we require more energy-efficient routing protocols to route data to the IoT hub [5,6].

A WSN-assisted IoT network is a unit of Low-power and Lossy Networks (LLNs) which are categorized as minimal power and energy-constrained devices that are interrelated with links, where LLN devices can act as data originator and router [7]. In LNNs, power conservancy and network lifetime improvement are the foremost challenges [8]. The routing over LLNs’ WG of the Internet Engineering Task Force (IETF) produced specifications for both the RPL protocol (RFC 6550) and a set of related extensions for various routing metrics, objective functions, and multicasts. The wireless links in LNN are lossy because of the quality of radios and minuscule size of LNN, and the routing protocols in LLN provide routing within the network. The state-of-the-art routing protocols for WSN-assisted IoT networks can be classified into three types as flat, hierarchical, and location-based protocols [9].

All sensor devices in flat-type routing protocols perform an equal role in acquiring information from the environment and relaying it to the IoT hub. The distance between the devices is computed based on the received signal strength in location-based routing protocols. This information is used for efficient data transfer. Hierarchical routing protocols are the most widely used routing protocols for WSN-assisted IoT networks. They partition the whole network area into different regions. Each partition has a master node and many member nodes. The master node is responsible for gathering data from the member nodes and transmitting it to the hub. Additionally, it is capable of effectively balancing the load on the sensor devices by assigning distinct tasks to distinct devices. Hierarchical routing is a viable option for lowering energy consumption by eliminating redundant data transmission. Due to its high energy efficiency, it outperforms other types of routing protocols [10,11,12,13,14].

Section 2 presents an extensive literature survey and Section 3 describes the system model. Section 4 focuses on the protocol’s description as well as the algorithms that are used to develop it. Section 5 presents the findings of the simulation and Section 6 provides a conclusion and future research direction.

2. Literature Review

Various routing methods for WSN-aided IoT Networks have been suggested in recent years [15,16,17,18,19,20]. In this part, we look at a few of the many types of new protocols. The LBDD routing protocol defines a large vertical strip of devices centered horizontally on the deployment area [21]. It is separated into g-sized sets once more. In-line devices are those that are connected to this virtual infrastructure. The data from the device is sent down the line and stored by the first in-line device that comes across it. When an IoT device detects any data, it sends it to the closest in-line device. When a hub requests data, it sends a vertical request to the virtual route [22]. First, the aligned device delivers it in both directions along the line’s course. When a query is sent to the relevant data-containing sensor devices, the devices submit the data immediately to the IoT hub. The amount of queries issued might sometimes outnumber the data. Broadcasts are used by LBDD to transmit data requests over the network [23]. The line structure may be quickly and cheaply created. This line must be sufficiently wide to prevent hotspots. It lowers energy usage while increasing overhead. The AN Position Information Request packet (ANPIREQ) is sent from the source device to the ring. When the ring devices receive the request, they transmit the AN Location Information Response (ANPIRES) packet to the source, which provides the current AN’s position information. The source can transmit data to the AN after receiving the response packet from the ring node. By including a small number of nodes in the ring, the Ring Routing protocol minimizes control packets. The anchor device’s location is requested by the source device [24]. The anchor device location information packet is sent by the ring devices in response. The data is transmitted to the anchor device once the source device has the anchor device’s position information. By aggregating the smallest number of sensor devices into the closed loop, the impacts of control packets are decreased. The RRP1 protocol is designed to operate with small, inefficient broadcasts [25].

The Railroad protocol takes advantage of the rail infrastructure to store all of the metadata associated with event data. In railroad routing, there are four main procedures. Rail construction, event notification, query request, and data transmission are among these processes  [26]. When the gadget detects data, it sends the metadata associated with it to the closest station (group of rail devices). Platform devices are the equipment in the station. The process of rail building occurs just once during the set-up phase. To see if a device is on the rail, it has to know how far away it is from the nearest border device and network center. The rail is notified of the event summary via event notification messages. When the rail device receives the message, it creates a new station and sends the message to the station’s platform devices. The railroad differs from LBDD in that it introduces a significant feature: the hub’s inquiries are unicast rather than broadcast. The stations should be wide enough to accommodate the rail width. Finally, because the inquiry must travel a greater distance, the railroad protocol delays data transmission more than the LBDD protocol. To obtain the information, the hub sends out a query. In three stages, this question is transmitted to the source. Query forwarding on the rail, query circulation around the rail, and query notification to the source are all included. The inquiry is sent from the hub to its neighboring device and subsequently to devices along the way to the train. The inquiry circulates with the help of direction information after it enters the train. In the middle of its journey, it also inspects all of the stations. If any station has relevant data that the hub requires, the platform device sends a query notification message to the source. After receiving the query notification message, the source sends the data to the hub.

The whole network region is partitioned into four equal planes by one horizontal and one vertical strip in the Rendezvous-Based Routing Protocol (RBRP). The rendezvous region is a horizontal and vertical strip of land. This virtual structure divides the network into four sections: 1—horizontal left, 2—horizontal right, 3—vertical up, and 4—vertical down. This intersection acts as a gathering spot. Devices that operate in this cross section are known as backbone devices. A tree was created in this area and some of the backbone devices are part of it. This tree is responsible for data transmission from the source to the hub and from the hub to the source [27]. The hub position is known by the devices that participate in tree creation, while the hub position is unknown to the other backbone devices. Space partitioning is accomplished using the quadtree structure of the network via the quadtree-based routing protocol (QDD). The following assumptions guide the development of this protocol: All stimuli and hubs are movable, but IoT devices are stationary and aware of their location. They are also familiar with their one-hop neighbors. The IoT devices are aware of the whole WSN-assisted IoT network, which is defined as 2 m × 2 m, where m = log2. (N). For data and packet delivery, this protocol uses a greedy forwarding mechanism [28].

The building quadtree structure in QDD is modest as compared with other hierarchical techniques. The QDD has been unable to resolve the hotspot issue. For WSN-assisted IoT networks, the Centroid-Based Routing Protocol (CBRP) suggested an energy-efficient data routing protocol. It establishes the Candidate Cluster Head (CH) device, which ensures a consistent allocation of energy in the cluster. Cluster formation is delegated to the BS, which helps to reduce cluster formation overhead. The data packets are sent using a threshold distance. Data loss happens when the distance exceeds the threshold [29]. The procedure for re-electing cluster heads has yet to be established. The WSN-assisted IoT network is divided into sectors via the SCBC (Sector-Chain-Based Clustering Routing Protocol) (cluster). For each cluster, it creates a chain, with the chain leader functioning as the cluster head (CH) and secondary cluster head (SCH), both of which contain considerable residual energy. The SCH has the smallest distance between candidate nodes and the network’s base station (BS). The network’s energy dissipation is decreased by using chains for data transfer. When compared with the CH, the SCH is used to save energy. The Base Station (BS) establishes clusters and selects a cluster leader, resulting in higher energy use in following rounds [30].

The LEACH protocol is available in a variety of variants that improve its performance. Heinzelman et al. propose LEACH-C, which uses a fixed number of CHs in subsequent rounds and assigns CHs to clusters via a base station [31]. Clusters are formed only once during the setup phase of LEACH-F and persist for the duration of the network [32]. New IoT devices are not permitted to join the network in this configuration. The network is controlled by BS, which transmits data via single-hop communication. Biradar et al. [33] propose a multihop LEACH, in which an optimal multihop tree is constructed between all CHs, with the IoT hub as the root. This path is responsible for communication in the network. Another version, MS-LEACH, uses one-hop and multihop communication for transmission, which depends on the cluster size proposed by Qiang et al. [34]. Farooq et al. propose an MR-LEACH that divides the entire network area into layers depending on the hop distances among the cluster heads [35]. The data is transmitted from the lower layer’s CH to the nearest upper layer’s CH until it reaches the IoT hub. The existing protocols [32,33,34,35] increase the network lifetime but have a problem with hotspots in the network because of overtraffic near the base station. Researchers have tried to solve this problem by delivering more energy-efficient routing protocols such as a mobile IoT hub, multihop communication, constrained mobility of the IoT hubs, and grid-based routing protocols.

Sanchez et al. [36] propose the GMR multicast routing protocol. It mainly deals with multicast messages produced by the source IoT device. It finds the subset of IoT devices to send messages to all destinations with less bandwidth and utilizes minimal sensor resources such as battery, memory, and CPU usage. Here, the IoT devices know their position, and periodic beacons are used to send their position information to their neighboring IoT devices. The IoT devices are selected by using their position and running GMR for sending the data to destinations. The best subset of IoT devices can reduce the distance to destinations and reduce the overheads. If some neighbors fail to reduce the distance to the destination, then face routing is used to exit local minima until it finds a new IoT device.

Buttyan and Schaffer proposed the PANEL routing protocol [37], which divides the network area into clusters geographically and deploys the IoT devices randomly. A PANEL elects the aggregator IoT devices in each cluster. Each aggregator IoT device receives queries from the IoT hub. Here, the processing time is divided into epochs, and for each epoch, a different aggregator IoT device is selected for load balancing in the network. PANEL routing may be of two types. Routing within the cluster is called intracluster routing. Here, the message from IoT devices is routed to current or former aggregator IoT devices. Routing among the clusters is called intercluster routing, where the messages come from a distant source. It suffers from IoT device depletion when cluster connections become divided, which causes the election of more than one within-cluster aggregator. Akl and Sawant proposed a Grid-based Coordinated Routing protocol in which the total network area is divided into small-sized (user-specified) grids [38]. Each grid has a coordinating IoT device that determines the routing. The source IoT device floods data and queries to the network. The IoT hub responds to these queries by sending information back on the reverse path. This process continues until any coordinating IoT device’s energy becomes depleted or the connectivity is lost between the IoT hub and the source due to the network’s partition. A new coordinating IoT device is selected from the grid based on its ID. For example, the second-largest ID is selected when the first becomes exhausted. To preserve energy, noncoordinating IoT devices can sleep by shutting their radio signal.

Das et al. proposed a hierarchical Rendezvous Point Multicast (HRPM) protocol that divides a group into smaller groups [39]. A distributed geographic hashing concept is used for building and maintaining a hierarchy with no additional cost. The network field is divided into square cells of equal size until we reach a cell with a manageable number of IoT devices, and each cell is controlled by an Access Point (AP). Two approaches are used to increase the scalability of location-based multicast: distributed mobile geographic hashing and the hierarchical breakdown of large multicast groups. They provide lightweight hierarchical membership management, reducing per-packet encoding overhead without the significant expense of maintaining distributed state at mobile nodes. The members of the multicast tree fix the rendezvous point as a group manager. A virtual source to AP tree is built from the source that transmits data to this (source to AP) tree. An overlay tree consisting of AP members transfers packets to IoT devices in the group, and Face routing handles the holes in HRPM.

Koutsonikolas et al. proposed a Hierarchical Geographic Multicast Routing Protocol (HGMR) that uses both GMR and HRPM for static networks, providing forward efficiency and reduced encoding overhead [40]. In HGMR, the subgroups’ hierarchy is designed to reduce encoding overhead. HRPM’s unicast method is used for delivering the data from the source to the AP tree, and GMR’s broadcast-based forwarding method is used for AP to member tree to reduce transmission numbers. AP monitors destination IoT devices in every cell, and these are selected by using the localized neighbor selection method of the GMR. The trees in HGMR are not overlay as in HRPM. Banimelhem and Khasawneh propose a grid-based multipath routing protocol (GMCAR) that avoids congestion and supports QoS traffic for WSN [41]. This protocol is proactive, hierarchical, and supports multipath. The protocol consists of three phases: grid formation, building routing tables, and data transmission phases. The entire network is divided into small, square-shaped grids of predefined size, containing a master and nonmaster IoT device. It is the first protocol to use the concept of finding the diagonal paths between the master IoT device and the IoT hub. It also considers the density of IoT devices as a decision factor for data forwarding. The master IoT device is responsible for data routing from nonmaster IoT devices and other master IoT devices to the IoT hub. A routing table is built for each master IoT device to know other masters’ IoT device positions to send the data diagonally until it reaches the IoT hub. The IoT hub sends a flooding message to enable master IoT devices to find the paths from the grid to the IoT hub. Master IoT devices collect the data from grid members and select the next master IoT device to send the data. This process is continued until the energy of the master IoT device is exhausted. The master IoT device selects a new IoT device based on residual energy. The GMCAR uses two routing techniques for high and low traffic to boost network lifetime.

An energy-aware grid-based routing technique named EAGER for WSN is proposed by Chi and Chang [42]. Grids are constructed in the network, and each grid is assigned with a unique grid ID. An IoT device is selected as a grid head in each grid, which has information about the neighboring grid heads. The TDMA technique is used for keeping the grid heads active depending on the sum of coordinates. The grid head of the source IoT device sends a request packet for path building. The IoT hub’s Local Grid Head (LGH) replies with a reply packet that reached the source’s LGH, so this path transmits the data. When the IoT hub moves to another location, the IoT hub’s path is extended by the IoT hub, and rerouting is used for constructing a path to the IoT hub. Khan et al. proposed VGDRA, where the network area is divided into grids containing equally sized cells [43]. Cell headers are the IoT devices close to the center of the cell. For the communication between neighboring cells, gateway IoT devices are elected. Cell headers can keep the information regarding the IoT hub’s present location by constructing a virtual backbone structure with gateway IoT devices. Data communication takes place between member IoT devices and their closest cell header. Cell headers collect the data from member IoT devices and transfer them to mobile IoT hubs. The IoT hub flows in the network to collect data from the border cell header. The route’s re-adjustment can be performed by a border cell header, which is very close to an IoT hub.

The network reliability is the main concern for the existing routing protocols such as PCMRP. It creates a multipath by flooding control packets across the network. This is a significant contributor to the increase in control packet overhead. Additionally, the multipath is reconstructed if any device becomes the source. This adds to the protocol’s overhead [44]. The REDCL method prioritizes the selection of a fewer number of active reporting nodes (ARNs) in hotspot areas over the selection of more ARNs in nonhotspot areas. The REDCL method converges the paths of several ARNs monitoring an event outside of nonhotspot zones and sends them to the hub after data aggregation. The hotspot area’s ARNs are unable to transfer data directly to the hub. They must communicate with the hub through nonhotspot ARNs. This intern places an additional burden on nonhotspot ARNs. As a result, the energy consumption of nonhotspot ARNs is rather high, therefore increasing the overall energy consumption of the network [45].

Suresh and Sharma proposed VGBST consists of a group of cells that are responsible for rebuilding new routes depending on the present location information of the IoT hub [46]. A virtual infrastructure is designed by dividing the entire field into grids of equal-sized cells. The selection of cell headers in the network depends on the IoT devices, which are very close to the cell’s center, which monitors the mobile IoT hub’s position. The rest of the IoT devices other than CHs send data to the closest CH, and this CH forwards to the CH adjacent to it by using gateway IoT devices. Grid-Based Reliable Routing (GBRR) was proposed by Meng et al., where communication quality helps choose the succeeding communication hop [47]. It is performed by creating virtual square grids of equal size such that each grid contains a few IoT devices. Total energy consumption is minimized with the help of the present position of IoT devices and grids, which is helpful for clustering. A cluster can occupy one or more grids, and the elected CH is responsible for managing the intracluster and intercluster communication. The routing algorithm helps to construct the productive paths inside a cluster and between the clusters to avoid overloading. All IoT devices are not used in the path while transferring the data from the source IoT device to the base station.

A Mode-Switched Grid-Based Sustainable Routing Protocol (MSGR) for Wireless Sensor Networks is an energy-efficient routing protocol which partitions the entire sensing region into virtual grids of equal size [48]. In this scheme, each grid IoT device is selected as a grid head, and the path to the IoT hub is constructed using the grid head. This scheme improves network lifetime by switching the grid heads between active and sleep modes such that every grid head does not take part in establishing a path to the IoT hub at the same time. A path is built to the IoT hub by the active grid heads. Data is sent directly to the IoT hub by active grid heads in the IoT hub path. From the grid head’s coordinate, we can infer whether it is in active or sleep mode.

Table 1. Comparison of Routing Protocols for WSN-assisted IoT Networks.

Protocol	Classification	Mobility	Energy	Scalability	Delay
CCS [49]	Chain Based	No	Very Low	Low	Large
EBCRP [50]	Chain Based	No	Very Low	Low	Large
PEGASIS [51]	Chain Based	No	Very Low	Very Low	Very Large
CHIRON [52]	Chain Based	No	Moderate	Low	Small
BATR [53]	Tree Based	No	Low	Low	Large
EADAT [54]	Tree Based	No	Moderate	Low	Large
PEDAP [55]	Tree Based	Yes	Moderate	Low	Moderate
ETR [56]	Tree Based	No	Moderate	Moderate	Moderate
TTDD [57]	Grid Based	Yes	Very Low	Moderate	Very Large
PANEL [37]	Grid Based	No	Moderate	Moderate	Moderate
HGMR [40]	Grid Based	No	Low	High	Moderate
GMCARE [41]	Grid Based	No	Moderate	Moderate	Moderate
RRP1 [25]	Area Based	Yes	Moderate	Moderate	Moderate
LBDD [21]	Area Based	Yes	Moderate	Moderate	Moderate
VLDD [58]	Area Based	Yes	Moderate	Moderate	Large
RRP2 [26]	Area Based	Yes	Moderate	Moderate	Large

illustrates the comparison among the existing protocols by considering several factors.

3. System Model

3.1. Assumptions

The WSN-assisted IoT network is made up of numerous sensor devices that are connected via a radio communication link operating within the radio range R. When the distance between two devices is less than the radio range R, the communication link is considered direct (one-hop); otherwise, the communication link is considered indirect (multihop). The network is comprised of k sensor devices and an IoT hub. The IoT hub is equipped with an infinite amount of memory, processing, and battery power. The devices can estimate the Received Signal Strength Indication (RSSI) value of the received signal. This protocol is well-suited for applications that require periodic sensing.

3.2. Energy Consumption Model

We should incorporate receiving and sending energy for IoT devices when calculating IoT device energy usage. Let $ETrans(n,d)$ denote the cost of transmitting n bits of data over a distance of d meters and $ERecv\left(n\right)$ denote the cost of receiving n bits of data over the same distance [59].

For transmitting n bits:

$$E_{Trans}(n,d)=\left\{\begin{array}{cc}{E}_{Embb}*n+E_{Amp}*n*d^2,\hfill & d\le d_0\hfill \\ E_{Embb}*n+E_{Amp}*n*d^4,\hfill & d>d_0\hfill \end{array}\right.$$

For receiving n bits:

$$E_{Recv}\left(n\right)=E_{Embb}*d.$$

(1)

The energy spent by IoT device in sleeping state is:

$$E_{sleep}\left(t\right)=E_{low}*t.$$

(2)

where $E_{low}$ is the energy consumption of any device in sleep mode for one second. The total time consumed in sleep mode is t seconds.

Any IoT device in the network consumes a total energy of:

$$E_{Total}=E_{Trans}(n,d)+E_{Recv}\left(n\right)+E_{sleep}\left(t\right).$$

(3)

4. Proposed Protocol

The protocol under consideration, CRPSH, discovers all possible paths prior to their use. This technique is appropriate for static networks. CRPSH uses a clustering technique that needs the path between the CH and the hub. The hub is in charge of calculating the route discovery and regulating the energy consumption of every sensor device in the network. It is divided into four phases: peer discovery, cluster formation, data transfer, and re-clustering and rerouting.

4.1. Peer Discovery

After sensor devices are deployed, the IoT hub starts the peer discovery phase. Each sensor device broadcasts the $P_z{D}_{control}$ packet once in this configuration. Each device has knowledge about its peers at the completion of the peer discovery phase. The sender id is contained in the $P_z{D}_{control}$ packet. When a device obtains a $P_z{D}_{control}$ packet, it checks the peer list for the source device IDs. If the source ID is not yet in the peer list, it must be added; otherwise, the packet will be dropped. If the recipient device’s $P_z{D}_{control}$ packet is set to false, the recipient device sets it to true and broadcasts the $P_z{D}_{control}$ packet.

The Algorithm 1 explains the above operations. The phase of topology building follows the phase of peer discovery. During this process, each device broadcasts information about its peers to the IoT hub. Each device does this by employing a multicasting approach rather than flooding. The devices begin transmitting peer information to the hub via relay devices. As explained in Algorithm 1, the sender device selects a relay device from $P_z\left(\alpha \right)$ and passes peer information to the hub. A sensor device transmits the $P_z{D}_{info}$ packet just once to avoid network loops. Each device does this by maintaining a list of received peer information. As a result, it lowers network traffic and conserves energy. When the hub receives the $P_z{D}_{info}$ from the sensor devices, it constructs the peer adjacency matrix. This peer adjacency matrix represents the network structure. The hub determines the cluster heads and the routing paths between them based on the peer adjacency matrix.

Algorithm 1 Peer Discovery

INPUT: Peer Discovery Control Packet

OUTPUT: Return Hub Adjacency Matrix

1: $P_z\left(\alpha \right)$ = $\varphi$ where $P_z\left(\alpha \right)$ = { w : w are the Peer/ Neighbor Device of the device $\alpha$};

2: $P_{z}Table\left(\alpha \right)$ = $\varphi$ where $P_{z}Table\left(\alpha \right)$ is the Peer/ Neighbor table of the IoT Device $\alpha$;

3: $E_R\left(\alpha \right)$ is the remaining energy level of the IoT Device $\alpha$;

4: Initially $P_z{D}_{control}\left(\alpha \right)$ = False;

5: Set $P_z{D}_{control}\left(\alpha \right)$ = True when the the IoT Device $\alpha$ sends the $P_z{D}_{control}$ packet;

6: $Spo{t}_{\alpha }$ is the location of the IoT Device $\alpha$;

7: Device $\alpha$ receives the control packet $P_z{D}_{control}$ : <$P_z{D}_{control}$, $I{D}_{\beta }$$E_R\left(\beta \right)$, $Spo{t}_{\beta }$> from the Device $\beta$;

8: if $\beta$ ∉ $P_{z}Table\left(\alpha \right)$then

9:    $P_z\left(\alpha \right)$ = $P_z\left(\alpha \right)$ ⋃ $\beta$;

10:    Update $P_{z}Table\left(\alpha \right)$ with <$I{D}_{\beta }$, $E_R\left(\beta \right)$, $Spo{t}_{\beta }$>;

11:    if $P_z{D}_{control}\left(\alpha \right)$ == false then

12:        $P_z{D}_{control}\left(\alpha \right)$← True;

13:        Broadcast $P_z$$D_{control}$ : <$P_z{D}_{control}$, $I{D}_{\alpha }$>;         ▹ Broadcast $P_z{D}_{control}$ packet;

14:    else

15:        Discard the packet

16:    end if

17:    Discard the packet

18: end if

19: Device $\alpha$ receives the control packet $P_z{D}_{info}$ : < $P_z{D}_{info}$, $P_{z}Table\left(\beta \right)$, $I{D}_{\beta }$, $I{D}_{relay}$ > from the Device $\beta$;

20: if $I{D}_{relay}$ = $I{D}_{\alpha }$ then

21:    if $\beta$ ∉ $P_z{D}_{info}\left(\alpha \right)$ then

22:        $P_z{D}_{info}\left(\alpha \right)$ = $P_z{D}_{info}\left(\alpha \right)$⋃$\beta$;

23:        if $I{D}_{\alpha }$ == $I{D}_{Hub}$ then

24:           Update peer adjacency matrix using $P_{z}Table\left(\beta \right)$;

25:        else

26:           Forward the $P_z{D}_{info}$ packet to the selected relay node;

27:        end if

28:        Discard the packet

29:    end if

30:    Discard the packet

31: end if

4.2. Cluster Head Selection and Cluster Formation

Initially, the energy levels of all devices are equal. The hub computes and tracks the remaining energy of every device after building the peer adjacency matrix. The hub selects CHs in the network based on the following criteria:

1.

Two CHs should not be located adjacent to one another.

• Let Device $\alpha$ be selected as CH;
• $P_z\left(\alpha \right)$ is a set peer device of the Device $\alpha$;
• if ($\beta \in P_z\left(\alpha \right)$) then
•     Device $\beta$ cannot be CH.
• end if

2.

Each CH’s residual energy, $E_R\left(CH\right)$, should be larger than the threshold value.

3.

Each cluster head should have a peer count of at least $\gamma$ /2.

• Let k be the number of devices in the network and c denote the ideal number of CHs.
• Then, $\gamma$ = (k-c)/c. In the ideal situation, $\gamma$ is the average number of devices in a cluster. So each CH should satisfy $P_z\left(\alpha \right)$⩾$\gamma$ /2.

After choosing the CH, the hub calculates the path from hub to the CH. The hub checks the peer adjacency matrix and ensures that the selected sensor device’s energy level is more than the threshold. Moreover, The routing path’s total energy usage should be kept to a minimum. To inform the sensor devices that have been selected as CHs, the hub unicasts the announcement packet ($C{H}_{announce}$) to the cluster heads through the path determined in Algorithm 2. The $C{H}_{announce}$ packet then proceeds along the route to the CH. Reverse connections are made by the sensing devices along the way to the CH. A $CHannounce$ message causes the CH to send a $CHack$ acknowledgment packet to the hub. The $C{H}_{ack}$ packet takes the same way back as the $C{H}_{announce}$ packet. If the hub does not receive an acknowledgment packet from the CH within a specified time period, it takes a different routing.

Algorithm 2 Cluster Head Announcement

INPUT: Hub sends $C{H}_{announce}$ packet to the Cluster Heads.

OUTPUT: Cluster Heads send $C{H}_{ack}$ packet to the hub.

1: $Route\left(k\right)$ is a collection of sensor devices that form the route between node k and the hub.

2: Each relay device maintains a routing table $Real{y}_{Table}\left(\alpha \right)$ with two columns: cluster head $id$ and $next\_device$, which is initialized to $\varphi$.

3: Device $\alpha$ receives the $C{H}_{announce}$ packet from the Device $\beta$;

4: $C{H}_{announce}$ : < $C{H}_{announce}$, $Route\left(CH\right)$, $I{D}_{\beta }$, $I{D}_{CH}$ >

5: if ($I{D}_{CH}$ == $I{D}_{\alpha }$) then

6:    Forward the ACK Packet $C{H}_{ack}$ : < $C{H}_{ack}$, $I{D}_{\alpha }$, $next\_device$ > towards the hub.

7: else

8:    if ($\alpha \in$ Route (CH)$\&\&I{D}_{CH}\notin Real{y}_{Table}\left(\alpha \right)$) then

9:        Update the $Real{y}_{Table}\left(\alpha \right)$ by updating cluster head $id$ as $I{D}_{CH}$ and $next\_device$ as $I{D}_{\beta }$;

10:        Broadcast $C{H}_{announce}$ : < $C{H}_{announce}$, $Route\left(CH\right)$, $I{D}_{\alpha }$, $I{D}_{CH}$ > packet.

11:    else

12:        Discard the packet;

13:    end if

14: end if

15: $C{H}_{ack}$ : < $C{H}_{ack}$, $I{D}_{\beta }$, $next\_device$ >

16: if ($next\_device==I{D}_{\alpha }$) then

17:    if ($I{D}_{\alpha }==I{D}_{Hub}$) then

18:        $Time\_out\leftarrow false$;

19:    else

20:        Find the $next\_device$ of CH $\beta$ from the $Real{y}_{Table}\left(\alpha \right)$;

21:        Forward the ACK Packet $C{H}_{ack}$ : < $C{H}_{ack}$, $I{D}_{\beta }$, $next\_device$ > towards the hub.

22:     end if

23: else

24:     Drop the packet.

25: end if

Afterward, the cluster head broadcasts the $C{H}_{info}$ advertisement packet to create a cluster as shown in Algorithm 3. The devices that receive several $C{H}_{info}$ packets pick the cluster head based on the RSSI value that is the highest RSSI. After the CH selection, a device sends the $C{H}_{join}$ packet with the joining request. Each interested device sends an equivalent $C{H}_{join}$ packet to the cluster head. Following receipt of all joining requests, the cluster head broadcasts information to the hub about each cluster member. The CH utilizes Time Division Multiple Access (TDMA) to create a time-slot schedule for the cluster members and distributes it to them to alleviate congestion. This TDMA slot can be used to maintain collision-free communication among the CHs and CMs.

Algorithm 3 Cluster Formation

INPUT: CH sends $C{H}_{info}$ packet packet to the CMs.

OUTPUT: CH sends $Cluste{r}_{member}\left(CH\right)$ to the hub and TDMA slots to each CM.

1: Device $\alpha$ receives the $C{H}_{info}$ packet from the Device $\beta$, where $\beta \in CH$

2: $C{H}_{info}$ : < $C{H}_{info}$, $I{D}_{\beta }$ >

3: Device $\alpha$ selects the CH with the maximum received signal intensity as its CH after receiving all $C{H}_{info}$ packets.

4: Device $\alpha$ sends the $C{H}_{join}$ packet to the selected CH.

5: Device $\alpha$ receives the $C{H}_{join}$ packet from the Device $\beta$, where $\alpha \in CH$

6: $C{H}_{join}$ : < $C{H}_{join}$, $I{D}_{\beta }$, $I{D}_{CH}$ >

7: if ($I{D}_{\alpha }$ == $I{D}_{CH}$) then

8:    $Cluste{r}_{member}\left(\alpha \right)\leftarrow Cluste{r}_{member}\left(\alpha \right)\cup \beta$;

9:    Device $\alpha$ sends the $Cluste{r}_{member}\left(\alpha \right)$ to the hub after receiving all the $C{H}_{join}$ packets.

10:  Device $\alpha$ sends the TDMA slots to each CM.

11: else

12:  Discard the packet.

13: end if

Lemma 1.

The clustering process needs the transmission of $\mathcal{O}\left(\alpha \right)$ control messages, where α is the number of sensor devices in the network.

Proof. 

Each device begins the cluster formation process by broadcasting a $P_z{D}_{control}$ packet. Thus, the network contains $\alpha$ messages. Each device communicates information about its peers to the hub, which accepts $\alpha$ messages again. To join the cluster head, every cluster member broadcasts a $C{H}_{join}$ packet. Assume that the number of cluster heads created is $\beta$. Thus, the total number of join requests is ($\alpha -\beta$), and the cluster heads require $\beta$ messages for each time slot. Thus, in cluster formation, the total number of control messages required is $\alpha$ + ($\alpha -\beta$) + $\beta$ + $\beta$ = 2$\alpha$ + $\beta$. As a result, the overall complexity of the control message throughout the cluster formation network is O($\alpha$). □

Lemma 2.

The network’s total energy usage is $E_{Total}=\sum \left((E_{ch}\times \beta +E_{cm}\times (\alpha -\beta ))\right)$.

Proof. 

Each device in CRPSH is classified as a cluster head or a cluster member. Cluster members transmit data to the CH, which collects and delivers the data to the hub. The transmission, receipt, and aggregation of data by the each cluster head requires $E_{ch}$ energy. Each cluster member uses $E_{cm}$ energy during transmission, reception, and sleep. If the number of CHs in the network is $\beta$, then the network’s total energy usage is $E_{Total}=\sum \left((E_{ch}\times \beta +E_{cm}\times (\alpha -\beta ))\right)$. □

4.3. Data Transmission

Within the specified time, the cluster member transmits the sensed data to the CH and then enters sleep mode. In the subsequent time slot, the sensor device reactivates to transmit the data. As a result, the protocol optimizes the energy efficiency of the sensor devices. The CH collects data and transmits it to the hub via the specified path. The CH receives an acknowledgment packet when the data arrives at the hub. The data is re-transmitted if the CH does not receive confirmation from the hub. Because the hub contains all of the network’s topological information, it continuously monitors each device’s remaining energy. If the hub detects that a device’s residual energy is less than the predefined threshold, it redirects the CH to another available path.

4.4. Re-Clustering and Rerouting

The hub continually monitors each device’s remaining energy to ensure that the load is distributed evenly among the devices. If a device’s energy level falls below the threshold, the hub begins re-clustering or rerouting according to the role of the device. If the device is a relay device for any path, the hub chooses another way to bypass it. If the device is a CH, the hub switches to a different CH and path. This approach extends the network’s life. If a device has less residual energy than the threshold, it does not participate in routing or becoming a CH but instead functions as a cluster member.

5. Simulation Results

The complete set of simulations is carried out using Castalia simulator.

Table 2. Simulation Parameters.

Parameter Name	Value
Network Size	$100\times 100$ m ${}^2$
Number of sensor devices	100
Data packet size	512 bytes
Control packet size	32 bytes
Initial energy	1 J
$E_{Embb}$	50 nJ/bit
$E_{fs}$	10 pJ/bit/m ${}^2$
$E_{mp}$	0.0013 pJ/bit/m ${}^4$
$d_0$	87 m
$E_{Comp}$	5 nJ/bit
$E_{low}$	0.2 nJ/s
Simulation time	400 s
MAC protocol	TMAC

shows the parameters used for simulation.

5.1. Average Energy Consumption

The average energy consumption for each protocol is depicted in Figure 1. It is observed that the proposed protocol (CRPSH) has a lower control packet overhead than PCMRP and REDCL. The proposed scheme does not employ flooding and does not involve the entire network in selecting CHs and multipaths. The hub selects the CHs and routing paths on its own. PCMRP, on the other hand, creates a multipath by flooding control packets across the network. This is a significant contributor to the increase in control packet overhead. Additionally, the multipath is reconstructed if any device becomes the source. This adds to the protocol’s overhead. PCMRP transmits data via the shortest path possible. However, because of the increased overhead associated with control packets, the average energy consumption is higher.

The efficiency of the routing protocol relies on energy consumption. The smaller the network energy consumption, the greater the network lifetime. Therefore, it is the total energy consumed by IoT devices to perform transmission, reception, processing, and sleeping activities.The REDCL method prioritizes the selection of a smaller number of active reporting nodes (ARNs) in hotspot areas over the selection of more ARNs in nonhotspot areas. The REDCL method converges the paths of several ARNs monitoring an event outside of nonhotspot zones and sends them to the hub after data aggregation. The hotspot area’s ARNs are unable to transfer data directly to the hub. They must communicate with the hub through nonhotspot ARNs. This intern places an additional burden on nonhotspot ARNs. As a result, the energy consumption of nonhotspot ARNs is rather high, therefore increasing the overall energy consumption of the network.

5.2. Average End-to-End Delay

It is calculated as the time it takes for a data packet to be generated at the source and received successfully at the sink. Each potential cluster head in the PPCMP must wait before becoming the cluster head. Furthermore, when the source node changes, the protocol must recreate the multipath for the new source node for each new event. This increases the protocol’s total latency. The REDCL approach sends data packets to the principal route based on a single event. It collects data before sending it to the hub, which causes packet delivery to be delayed. CRPSH, on the other hand, allows for various pathways to be taken. The proposed protocol has a more reduced end-to-end latency than PCMRP and REDCL, as shown in Figure 2.

Conversely, for CRPSH, multiple paths are available. The result in Figure 2 indicates that the proposed protocol’s end-to-end latency is less than that of PCMRP and REDCL.

5.3. Packet Delivery Ratio

It is defined as the ratio of IoT hub receipt data packets to data packets sent by the source. For each protocol, the packet delivery ratio is illustrated in the Figure 3. PCMRP employs node-disjoint multipath routing, that improves reliability and, as a result, the delivery ratio. The REDCL method aggregates data by converging multiple routes of event monitoring devices into a single route. As a result, its packet delivery ratio is more than that of PCMRP. However, under the proposed approach (CRPSH), the hub picks the path and keeps track of each device’s remaining energy. When it detects that a device’s remaining energy is less than the threshold, it switches to a different path for data transmission. As a result, data loss is minimal.

5.4. Network Lifetime

It is the time duration where the network works perfectly. For each protocol, the network lifetime is illustrated in the Figure 4. The proposed approach clearly outperforms the REDCL and PPCMP in terms of network lifetime. This is because it uses fewer control packets and distributes the workload properly across all the sensor devices.

6. Conclusions

This paper proposed a Cluster-based Routing Protocol with Static Hub (CRPSH) for WSN-assisted IoT networks. Sensor devices are often densely distributed across the network, and a monitoring zone may be covered by many sensor devices, resulting in redundant data. In CRPSH, we have used the clustering technique to reduce the duplicate data. CRPSH lowers the burden on the regular sensor devices and assigns more responsibilities such as clustering, route selection, and energy management to the hub.

The network reliability is the main concern for the existing routing protocols. In CRPSH, the multipath approach increases the proposed protocol’s reliability. Correspondingly, we compared CRPSH’s performance to existing models, such as PCMRP and REDCL, and discovered that CRPSH is energy efficient and extends the network’s lifetime and packet delivery ratio.

However, CRPSH often suffers from hotspot problems. The devices closer to the hub drain their energy at a faster rate compared with other devices (devices located at a far distance from the hub) as they have to perform more communication, and hence the whole network may become detached or isolated. A mobile hub is a possible solution to the hotspot problem.