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 illustrates the comparison among the existing protocols by considering several factors.
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 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 packet. When a device obtains a 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 packet is set to false, the recipient device sets it to true and broadcasts the 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 and passes peer information to the hub. A sensor device transmits the 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 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: = where = { w : w are the Peer/ Neighbor Device of the device }; |
2: = where is the Peer/ Neighbor table of the IoT Device ; |
3: is the remaining energy level of the IoT Device ; |
4: Initially = False; |
5: Set = True when the the IoT Device sends the packet; |
6: is the location of the IoT Device ; |
7: Device receives the control packet : <, , > from the Device ; |
8: if ∉ then |
9: = ⋃ ; |
10: Update with <, , >; |
11: if == false then |
12: ← True; |
13: Broadcast : <, >; ▹ Broadcast packet; |
14: else |
15: Discard the packet |
16: end if |
17: Discard the packet |
18: end if |
19: Device receives the control packet : < , , , > from the Device ; |
20: if = then |
21: if ∉ then |
22: = ⋃; |
23: if == then |
24: Update peer adjacency matrix using ; |
25: else |
26: Forward the 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 be selected as CH;
is a set peer device of the Device ;
if () then
Device cannot be CH.
end if
- 2.
Each CH’s residual energy, , should be larger than the threshold value.
- 3.
Each cluster head should have a peer count of at least /2.
Let k be the number of devices in the network and c denote the ideal number of CHs.
Then, = (k-c)/c. In the ideal situation, is the average number of devices in a cluster. So each CH should satisfy ⩾ /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 () to the cluster heads through the path determined in Algorithm 2. The packet then proceeds along the route to the CH. Reverse connections are made by the sensing devices along the way to the CH. A message causes the CH to send a acknowledgment packet to the hub. The packet takes the same way back as the 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 packet to the Cluster Heads. |
OUTPUT: Cluster Heads send packet to the hub. |
1: is a collection of sensor devices that form the route between node k and the hub. |
2: Each relay device maintains a routing table with two columns: cluster head and , which is initialized to . |
3: Device receives the packet from the Device ; |
4: : < , , , > |
5: if ( == ) then |
6: Forward the ACK Packet : < , , > towards the hub. |
7: else |
8: if ( Route (CH)) then |
9: Update the by updating cluster head as and as ; |
10: Broadcast : < , , , > packet. |
11: else |
12: Discard the packet; |
13: end if |
14: end if |
15: : < , , > |
16: if () then |
17: if () then |
18: ; |
19: else |
20: Find the of CH from the ; |
21: Forward the ACK Packet : < , , > towards the hub. |
22: end if |
23: else |
24: Drop the packet. |
25: end if |
Afterward, the cluster head broadcasts the advertisement packet to create a cluster as shown in Algorithm 3. The devices that receive several packets pick the cluster head based on the RSSI value that is the highest RSSI. After the CH selection, a device sends the packet with the joining request. Each interested device sends an equivalent 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 packet packet to the CMs. |
OUTPUT: CH sends to the hub and TDMA slots to each CM. |
1: Device receives the packet from the Device , where |
2: : < , > |
3: Device selects the CH with the maximum received signal intensity as its CH after receiving all packets. |
4: Device sends the packet to the selected CH. |
5: Device receives the packet from the Device , where |
6: : < , , > |
7: if ( == ) then |
8: ; |
9: Device sends the to the hub after receiving all the packets. |
10: Device 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 control messages, where α is the number of sensor devices in the network.
Proof. Each device begins the cluster formation process by broadcasting a packet. Thus, the network contains messages. Each device communicates information about its peers to the hub, which accepts messages again. To join the cluster head, every cluster member broadcasts a packet. Assume that the number of cluster heads created is . Thus, the total number of join requests is (), and the cluster heads require messages for each time slot. Thus, in cluster formation, the total number of control messages required is + () + + = 2 + . As a result, the overall complexity of the control message throughout the cluster formation network is O(). □
Lemma 2. The network’s total energy usage is .
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 energy. Each cluster member uses energy during transmission, reception, and sleep. If the number of CHs in the network is , then the network’s total energy usage is . □
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.