1. Introduction and Tutorial Contributions
The emerging socio-economic impacts of climate change and increasing global population on agriculture production are threats to both global security and food security since over one-third of the economically active global population obtains its livelihood from agriculture [
1]. This erratic change in weather and rainfall patterns due to climate change is a critical risk factor to crop productivity. Currently, the extent of climate-change-induced drought, according to
Figure 1, makes traditional rainfall-dependent farming in Africa, the global food basket, no longer reliable for minimizing the skyrocketing food insecurity and the associated unemployment risks. For instance, in Africa, the focus of this research, over 70% of the economically active population who rely on agriculture for their livelihoods can face severe unemployment threats [
1,
2] if this challenge persists any longer. In addition, over 60% of economic development supports are obtained from agriculture in Africa. These call for a paradigm shift in farming techniques, and the most promising game-changer is a robust, affordable, autonomous, and optimized, innovative WSN-based Agri-IoT technology. Precision farming and greenhouses with an underlying technology of WSN-based Agri-IoT are expected to replace traditional rainfall-dependent agriculture in the next decade in order to address food insecurity, reduced crop quality, and the alarming unemployment threats created by severe climate change-induced droughts and the increasing global population [
3]. These call for a paradigm shift in farming techniques, and the most promising game-changer is a robust, affordable, autonomous, and optimized, innovative WSN-based Agri-IoT technology that satisfies the critical design expectations presented in
Figure 2.
Although few surveys and tutorials have been authored on this subject, they present mere classifications of communications trends on classical IoT [
2,
5,
6,
7,
8] without any context-specific technical considerations of the critical design expectations in
Figure 2. For instance, the authors in [
2,
6,
7] examined IoT’s communication infrastructure, platforms, standards, development trends, and possible network solutions in agriculture. Similarly, the roles of industrial IoT (thus, identification-based IoT (example, RFID [
6], WSN[
9], QR codes [
5], barcodes) and communication-based IoT (example, ZigBee [
5], Z-wave [
6], MQTT [
5,
6], LoRa [
10], SigFox [
11], BLE [
12], Li-Fi [
5], Wi-Fi [
13], Near Field Communication-NFC [
5], and Power line area network) were reviewed in terms of current research trends, key technological applications, and main challenges in [
5]. Although RFID tags and WSNs have similar data acquisition capacities, the authors concluded that WSN technology is more energy-efficient and suitable for Agri-IoT than the costly RFID technologies [
5]. Consequently, to date, Agri-IoT technology has not brought about its intended paradigm transformation in the agricultural sector due to several technical challenges that have not received adequate contextual research considerations [
14]:
The agricultural setting is a unique area where conventional IoT technologies do not apply. Existing Agri-IoT solutions are location-restricted because they are mostly based on Wi-Fi or cellular communication technologies and electricity grids with constrained coverages in Africa. A typical African agricultural setting lacks access to reliable electricity and the Internet, and the intended users (farmers) of Agri-IoT technology are low-income earners with limited technological expertise. They are also based on LoRa, SigFox, cellular-based, and Wi-Fi-based technologies that require either licensing or reliable electricity/Internet access in the farm, which is unrealistic in Africa. Common IoT applications mainly utilize architecture-restricted, high-resource-demanding routing techniques (
e.g., Routing over low-power and lossy networks protocol (RPL)), and communication standards (
e.g., 4G, 5G, ZigBee, LoRa, Wi-FI, and long term evolution (LTE)) [
15], which are difficult to access in typical African farms. Consequently, Agri-IoT users in Africa expect a new solution that is affordable, simple to deploy and operate by non-experts, location-unrestricted, supportive of large-scale farm management, and based on freely available technologies that do not require licensing. Additionally, unlike popular IoT use cases such as medical, vehicular, and industrial IoT, whose designs are mainly affected by critical factors including security, stable connectivity, and interference, respectively, Agri-IoT is compelled to drive on affordable battery-powered SNs, which make architecture, low-power communication technology, power optimization, cost, fault-tolerance, multihop routing, scalability, and environmental impact critical design factors in order to address its resource or deployment-induced challenges [
12,
16,
17].
High susceptibility to faults and failures: Agri-IoT networks are vulnerable to faults and failures since the resource-constrained SNs are densely deployed in hostile environments to autonomously operate via a network supervisory protocol with limited post-deployment maintenance services. By implication, this supervisory protocol must incorporate sufficient power optimization, auto-fault management (FM), and self-adaptability techniques in order to achieve the desired performance expectation. Due to the lack of an in-depth and contextualized tutorial with such a capacity to bridge the gap between theoretical taxonomies and real-world designs, most canon Agri-IoT testbed solutions, such as authored in [
1,
10,
11,
17,
18,
19,
20], suffered abrupt failures during outdoor deployments.
Agri-IoT technology lacks comprehensive context-based synthesis from SN design to field deployment. The power- and resource-constrained SNs that form the WSN-based Agri-IoT system have limited data transmission rate, computational capabilities, memory capacities, communication distance, and operational stability. Consequently, the associated routing protocol [
9,
12,
17,
21], communication technology, and routing architecture [
22,
23,
24] must support mechanisms that ensure packet size and communication distance moderation [
16], efficient channel access management (CAM), and SN’s tasks management. It is not a mere application of conventional IoT to a farm as many authors attempted [
1,
10,
11,
17,
18,
19,
20]. Consequently, the WSN-based Agri-IoT technology requires contextualized overview. Because it extends classic IoT’s goals with additional application-specific requirements such as dense network inter-connectivity, higher information perceptibility, comprehensive intelligence services, remote monitoring, smart decision making, and the execution of precise control/actuation actions on the farm [
12,
23,
25,
26].
superficial consideration of desired communication technologies of Agri-IoT without considering the cluster-based architecture: To date, Agri-IoT-related surveys and tutorials focused on high-power-demanding communication technologies (Wi-Fi and cellular-based technologies), the centralized architecture-constrained ZigBee standard, and the operation principles of conventional IoT as authored in [
1,
10,
11,
14,
18,
19] without an in-depth consideration of the unique case of Agri-IoT. It is well established that the cluster-based architecture is the best candidate for Agri-IoT application [
12,
16,
17,
24]; however, there are no systematic evaluations to cement this fact. For instance, most benchmarking WSN-based IoT testbed solutions are founded on the topology-restricted ZigBee IEEE 802.15.4 communication standard and high-resource-demanding Wi-Fi, cellular-based, and 6LoWPAN/IPv6 routing standards. This standard also thrives on wired or fixed IP-based infrastructural backbones, total Internet/electricity coverage, and highly complex graph-based and centralized routing protocols [
1,
10,
11,
14,
18,
19]. As a result, these solutions are very complex and require full electricity and internet coverage. However, Africa, which is the focus of this study, has less than 50% electricity/Internet coverage [
27]. Hence, these location-restricted solutions lack global significance. Also, ZigBee, Wi-Fi and cellular-based communication technologies with centralized or flooding-based routing architecture [
1,
10,
11,
14,
18,
19] are capital-intensive, complex to manage, location-restricted, energy-inefficient, and over-reliant on fixed supporting infrastructure. Therefore, an in-depth contextual assessment of how low-power communication standards such as LoRa, SigFox, and Bluetooth Low-Energy (BLE) evolve in cluster-based Agri-IoT (CA-IoT) networks can be of immeasurable benefits to the IoT community and farmers.
The role of Agri-IoT in eliminating food insecurity, improving crop quality, alleviating global poverty, and increasing agricultural production volumes has been underestimated [2,7,8,10,16,28,29]. The agricultural sector, which has been hindered by climate change, is the largest global employer [
3]. To revitalize this sector, CA-IoT has emerged with the most promising opportunities to address food and employment insecurity issues and improve crop quality and economic conditions for the farmers. However, these benefits have not been fully realized due to insufficient research publicity.
In essence, an Agri-IoT system is useless if it does not perform to expectation and the users do not realize its full potential to fit the perfect needs of the farmers. Although IoT applications are founded on a common idea, each use case (
e.g., Agri-IoT) varies based on specific performance and users’ expectations as well as its technological, architectural, environmental, and deployment requirements [
1,
18]. Thus, an IoT ecosystem is a complex concept that cannot be easily classified because its characteristics evolve, adapt, or vary from deployment to deployment [
30]. Consequently, each use case requires an in-depth contextual evaluation of all vital aspects in order to realize its full potential.
To the best of our knowledge, no survey or tutorial articles have sufficiently considered these technical issues and provided sufficient technical guidelines for the designers of Agri-IoT systems to make well-informed decisions in order to achieve satisfactory network performance. Additional realistic research is needed regarding the contextual evaluation of SN design and deployment factors, fundamental network design concepts and requirements, multi-objective optimization (MOO) analysis of the parameters for designing the associated routing protocol, and efficient operational metrics of the WSN sublayer of the Agri-IoT using the cluster-based architecture. In addition, the assessment of the possibility of using low-power and accessible wireless communication technologies such as BLE via cluster-based architecture to achieve a complete infrastructure-less, cheaper, energy-efficient, self-healing, adaptive, and robust Agri-IoT network is imperative. Furthermore, a broader contextual overview covering all vital aspects such as the fundamental concepts of Agri-IoT, technical design requirements of SNs and WSN-based Agri-IoT, surveys of the benchmarking communication standards, routing protocols, and testbed solutions, and an in-depth case study on how to design a self-healing, energy-efficient, adaptive, and CA-IoT based on the performance and users expectations are illustrated in
Figure 2. Such a reference document can help support researchers when they attempt to accurately model and optimize the performance of Agri-IoT [
14] so that the performance gap between the simulated networks and the realized Agri-IoT testbed solutions [
1] can be addressed. By way of addressing these technical challenges, this tutorial presents the following contributions:
Perform an in-depth synthesis and review (1)the basic concepts of Agri-IoT, (2) the comprehensive design considerations of these networks, (3) the technical design requirements of Agri-IoT, and (4) the up-to-date research progress on routing techniques, communication standards, and testbed solutions of WSN-based Agri-IoT.
Systematically surveys the benchmarking of WSN-based IoT networks’ communication standards, FM techniques, routing and MAC protocols, and realization testbeds to respectively uncover the appropriate communication requirements for Agri-IoT, unveil the root faults and possible remedies in the WSN sublayer, derive a generalized taxonomy of routing architectures, and define appropriate routing paradigms for WSN-based Agri-IoT using the core PHY layer design metrics: affordability, self-healing capacity, energy-efficiency, location-independence, and network adaptability.
Systematic synthesis of canon cluster-based routing protocols to uncover the plethora of possible research gaps, derive a realistic taxonomy of MOO metrics and propose possible MOO remedies that can be implemented using CA-IoT routing architecture freely available low-power communication standards.
Proposition of MOO-induced guidelines in the form of open issues that can help Agri-IoT designers to build adaptive, robust, fault-tolerant, energy-efficient, affordable, and optimized CA-IoT networks in both simulation and real-world implementations.
Overall, this tutorial is motivated to provide a contextualized, in-depth understanding of this technology and assist the reader in designing robust, affordable, and optimized Agri-IoT networks that can act as reliable game-changer to avert the stipulated challenges. Also, the critical design, deployment, and QoS requirements of WSN-based Agri-IoT networks from theoretical modeling to real-world deployment are unveiled in order to bridge the existing gap between the theory and practice of this technology [
1,
14].
The remainder of this paper is organized into the following sections: Section II provides a brief background comparative overview of WSN, IoT, and Agri-IoT technologies, while Section III focuses on their components, protocols, architectural layers, and proposed architectural layers for WSN-based Agri-IoT technology. Section IV presents the detailed contextual design and implementation requirements of Agri-IoT networks, while Section V deduces the unique characteristics, challenges, and proposed performance expectations of the associated routing protocols for the WSN sub-layer of Agri-IoT. Sections VI, VII, and VIII present systematic surveys on routing protocols, FM techniques, and the canon real-world testbed implementations of WSN-based Agri-IoT solutions. Section IX examines how the above discussions have evolved using a case study of cluster-based Agri-IoT (CA-IoT) for precision irrigation, while Section X presents a sample design of a WSN-specific CA-IoT routing protocol. Section XI unveils open issues and future works, while Section XII concludes the chapter.
As presented in
Figure 3, the WSN-based Agri-IoT is an information- and knowledge-intensive intelligent feedback control system for farm monitoring, data sampling/computing, resource optimization, automation of farm operation (
e.g., precision irrigation, chemical application, livestock monitoring, and disease management [
16]), and actionable decision making via a variety of battery-powered and wirelessly-connected SNs with sensing, processing, and communication capacities [
2,
29,
31]. The SNs that form the WSN sublayer are spatially distributed and self-configured to achieve myriad remote sensing, surveillance/monitoring, and control applications via automated sensing, wireless communication, computing, making informed decisions, and actuation control [
32] using precise, accurate, and timely sampled information about a real-world phenomenon [
33].
The main hardware components of an Agri-IoT framework, as presented in
Figure 4 and
Table 1, include the WSN (
i.e., comprising of the field-deployed SNs or IoT devices), a base station (BS) or gateway or actuator controller, cloud servers, and the user’s monitoring/control devices. As aforementioned, the field participants (
e.g., SNs and BS) in Agri-IoT are mostly battery-powered and must be equipped with sensing, computing, and communication abilities to form infrastructure-less, robust, self-healing, and self-configured WSNs for data collection and event management [
34]. The core units of the SNs in
Figure 4c and the BS are compared and contrasted in
Table 1. As the framework in
Figure 4a depicts, the IoT devices can sense, process, and transmit their sampled data directly to the Internet or IoT cloud without a gateway. In contrast, the field-deployed SNs that form the WSN perform likewise via a BS. The BS interfaces between the IoT cloud/user and the WSN or actuator control system. Additionally, the BS is mostly resource-sufficient. It can process the received data and locally execute actionable decisions via the actuator of the farm event being monitored. The received data can also be relayed to the analytical data engines in the IoT cloud via a wired and wireless medium for further processing and actions [
13]. The resource-constrained WSN sublayer mainly uses data-centric protocols due to the SNs’ high deployment densities, high network dynamics, and limited power supply of SNs. Although data-centric protocols are fragile and not standardized, they are more suitable than the high resource-demanding ID-based IPv4 or IPv6 protocols in the addressing space of the WSN-based Agri-IoT.
1.1. Comparative Overview of WSN, IoT, And Agri-IoT Technologies
A comparative overview of the underlying technologies (
i.e., WSN, IoT, and Agri-IoT) forming the WSN-based Agri-IoT is required to help readers understand how the desired design expectations evolve in this ecosystem. A detailed comparison summary of these technologies in terms of architectural variations, users’ expectations, and design and implementational differences are presented in
Table 2.
As depicted in
Figure 4, WSNs are formed by spatially distributed, autonomous, resource-constrained SNs that wirelessly interconnect to communicate their sampled data to a BS for further monitoring or event tracking purposes without necessarily requiring the Internet. The main components of the WSN are the SNs, the BS/gateway, and the event sampling/routing software that supervises the entire network process. A node may route data directly or via relay SNs to the BS based on its location and assigned tasks. The BS locally performs the actionable decisions and execution of the actuation actions. Although the WSNs are resource-constrained and fault-vulnerable, they constitute the inevitable part of this technology [
2] and the underlying innovation of the WSN-based Agri-IoT framework.
In contrast, classic IoT consists of IoT devices that sense and transmit their sampled information directly or via telemetry to the internet for monitoring or event tracking purposes, mostly via the centralized routing architecture. Similar to the SNs in WSNs in
Figure 4, IoT devices are specialized and dedicated devices fitted with sensing, processing, communication, and power components that do not require centralized BS (gateway). Like BS in WSNs, IoT devices can connect to the internet/IoT cloud via fixed-line (thus, for a factory), 5G/4G/LTE cellular/mobile networks, or Wi-Fi for further processing, storage, and decisions/actions. Essentially, any stand-alone internet-connected device that can be monitored and controlled from a remote location can constitute an IoT network, which implies that a single-gateway WSN is a subset of IoT (
Figure 4).
Agri-IoT or WSN-based technology combines WSN and IoT technologies into contextualized intelligent farm management systems to achieve higher event data quality and offer remote monitoring and control. WSN-based Agri-IoT consists of the WSN sublayer, the gateways, the cloud servers, and the remote interface application, as illustrated in
Figure 4a and
Figure 8. Uniquely, the current trends of Agri-IoT mandate that both intra-SN and BS–cloud communication are based on low-power, ubiquitous, and freely available wireless standards [
2]. Also, most Agri-IoT solutions support bidirectional communications between the BS/gateway and the cloud/users, whereby the BS updates the cloud/user database and receives actionable/control remote messages from the user or cloud analytical decision results for actuation purposes. The WSN-based Agri-IoT is the most dominant technology in the global smart farming use cases in the agricultural sector. The core tasks of SNs in a WSN-based Agri-IoT application, which are frequently supervised by the associated routing protocol include, network construction/management, data sensing, data processing/aggregation, fault tolerance, and communication [
9,
12]. Also, the routing architecture must be supported by the associated communication platform and the application-specific requirements of the network.
Unlike IoT and WSN whose design expectations are application-specific, WSN-based Agri-IoT requires holistic integrations of the expectations in
Figure 2.
1.2. Classifications of IoT Applications and Specific Roles of Agri-IoT
Generally, IoT technology is application-specific. However, it has limitless applications and roles in the smart world agenda. Based on their intended purpose, WSN-based IoT systems can be broadly classified into condition monitoring and event tracking categories [
35], as illustrated in
Figure 5.
The monitoring-based applications involve real-time event data collection and analysis, supervision, and operational control of systems. In contrast, tracking-based applications track changes in the phenomenon of interest, such as the locations of objects, persons, transported goods, animals, and vehicles. Both application domains can be subdivided into industrial, environmental, and societal IoT applications in
Figure 5, where specific examples are provided for each application domain. For instance, monitoring-based applications may include indoor/outdoor environmental monitoring [
6], industrial process monitoring [
5,
29], process control [
2], greenhouse automation [
7], precision agriculture (
e.g., irrigation management, crop disease prediction, prediction of production quality, and pest and disease control) [
2,
8], biomedical or health monitoring [
8], electrical grid network monitoring/control [
12,
29], military location monitoring [
9], and so forth. Conversely, specific examples of tracking-based applications may include habitat tracking, traffic tracking, plant/animal condition tracking, and military target tracking, as outlined in
Figure 5.
1.3. Agri-IoT Roles and Use-Cases
The concept of intelligent farming involves data acquisition, data processing/planning, and smart control using the WSN and IoT technologies, big data, and cloud computing techniques to provide profitable solutions, presented in
Figure 6. These principal roles in
Figure 6 define their use cases. For instance, monitoring the state of crops or the climate of the field using Agri-IoT technology can allow farmers to know precisely the amount of pesticides, water, and fertilizers required to attain optimal crop quality and production volume. However, the QoS requirements, the routing techniques, architectural requirements, and the operational dynamics differ from one use case to another. This tutorial focused on the critical and unique design requirements of WSN-based Agri-IoT, which is the backbone of the smart agricultural initiative [
36]. The resulting use-cases in
Figure 6 can be explained as follows:
Agri-IoT for Climate Condition or Agronomical Monitoring: This Agri-IoT system mostly comprises BS (i.e. weather stations) and a deployed WSN. The analytical data engines mine the sampled climate or crop condition data in the cloud to predict future climate conditions and farm automation plans. The most suitable crop and precise farming practices can then be predefined to improve agriculture production capacity and quality.
Agri-IoT for Precision Farming: This is the most famous application of Agri-IoT, whereby farming practices (e.g. irrigation, fertilizer application, etc.) are precisely and accurately controlled to optimize these resources. Here, the SNs are mostly fitted with soil sensors to collect a vast array of microclimatic data (e.g. soil moisture, temperature, and salinity) that can enable farmers to estimate optimal amounts of water, fertilizers, and pesticides needed by the crops to minimize resources’ costs and produce healthier crops. Additionally, the BS controls the event actuation system via accurate data-driven real-time decisions on the crops using climate data, crop growth data, and disease infection data.
Agri-IoT for Greenhouse Automation: The Agri-IoT-based approach provides more accurate real-time information on greenhouse conditions, such as lighting, temperature, soil condition, and humidity, unlike manual greenhouse management. This allows precise remote monitoring and control or automation of all farming practices.
Agri-IoT for Livestock Monitoring and Management: In this system, SNs are attached to livestock to monitor their real-time health, track their physical location, and log their performance. This helps the farmer identify and isolate sick animals to avoid contamination and reduce staffing expenses.
Agri-IoT for Predictive Analytics: This Agri-IoT system provides highly relevant real-time data that can be analyzed to make essential predictions, such as crop harvesting time, the risk of disease infection, yield volume, yield quality, and yield vulnerability, for proper planning.
Agricultural Drones (Agri-Drones): Agri-Drones, such as DroneSeed, are fitted with mobile SNs and farming tools to collect agricultural data or perform activities such as field surveillance, crop planting, pest control, farm spraying, crop monitoring, etc. For example, For Agri-Drones, all the above use cases utilize the WSN-based Agri-IoT framework.
2. The Agri-IoT Ecosystem
The authors in [
1,
14] established that the existing real-world attempts of Agri-IoT could not meet both performance and user users’ expectations because they are founded on the fundamental concepts and the operational principles of classic IoT and WSN technologies. To effectively achieve the expectations in
Figure 2, it is imperative to conduct a systematic assessment of the related architectural layers in classic IoT and propose a suitable option for the WSN-based Agri-IoT ecosystem. Generally, the conventional IoT ecosystem consists of the network architectural layers and the data management platforms [
2,
7,
8], which are further grouped into devices (sensors, actuators, and gateways/BS), network (BS to cloud), platforms/applications’ cloud, and agents/users. Due to domain-specific requirements of IoT applications and the incorporation of numerous heterogeneous devices with application-specific requirements, there are generally no unified or standardized IoT architectural layers. Therefore, most application-defined layers are frequently adapted from the canon architectural layers, which include the 3-layer [
5], the cloud-based [
7], the service-oriented architecture (SOA) [
2,
7], and the fog-based [
2,
7,
29], as illustrated in
Figure 7.
The fog-based architecture was adapted from the 3-layer parent architecture to include cloud computing by offering computing, storage, and network information between the clients and the cloud services [
29] in a decentralized manner. Here, cloud computing and fog/edge computing architectures only differ in where data computing occurs. These layers are not unified because the respective network layers do not cover all underlying technologies that transfer data to all IoT platforms [
5]. Additionally, they are based on complicated centralized and flooding-based routing architectures, high-resource-demanding and capital-intensive Wi-Fi/cellular-based communication technologies. As well, they require wired infrastructural support in the farm, which is too complex, location-restricted, and capital-intensive for most low-income and non-expert farmers to implement and manage. Consequently, they are unsuitable candidates for the resource-constrained SNs in WSN-based Agri-IoT. By implication, there are no reference guidelines for designing Agri-IoT participants and supervisory protocols, controlling the speed of packet delivery, smoothing out SN’s integration, unifying technology, and creating standardized Agri-IoT reference models, among other considerations. In contrast, an Agri-IoT ecosystem, depicted in
Figure 4, consists of:
Agri-IoT network architectural layers: This shows how the physical network elements, network operation principles, and operational techniques interact throughout the entire ecosystem.
Network supervisory software/routing protocol and routing architectures: This contains the virtual arrangement of multiple network elements [
8] and the event sampling/routing protocol that constructs the routing architecture, supervises sampling and moderates all communications in the PHY layer.
Data management platform: It hosts all high-resource-demanding data analytic engines, event databases, and remote control algorithms in a cloud model.
2.1. Proposed Architectural Layers for WSN-based Agri-IoT
In designing an efficient Agri-IoT system of global significance, it is imperative to propose suitable architectural layers and evaluate how the various components interact in these layers. With the emerging advances in low-power, freely available, and boundless communication standards (
e.g., BLE) and unfulfilled potentials of CA-IoT network [
12,
16], a new framework of cluster-based architectural layers for the WSN-based Agri-IoT ecosystem is proposed in the left side of
Figure 8. The center portion of
Figure 8 presents the key components/technologies required in each layer, while the Things taxonomies of hardware components from related literature [
4,
8,
29] are depicted on the right portion of
Figure 8. The underlying layers in our 4-tier layers in
Figure 8 can be elaborated on as follows:
Integrated Application and Management Layer: This operates all agriculture-related applications that interface between the user (for example, farmer) and the Agri-IoT system to make decisions and execute remote actions to keep their crops or animals healthy. This layer manages the entire Agri-IoT system and its application-specific functionality, high-resource-demanding applications, and core business model in the cloud. This layer’s security requirements are crucial to the next sublayer; however, these are beyond the scope of this research. The Business or management sublayer maintains end-to-end data integrity and security by ensuring that data is transferred to the correct user. It also ensures that the correct user executes the actuation.
Information Management Layer: This handles data processing, storage, and other specialized cloud services and functionality that make precise, actionable decisions. In Agri-IoT, the sensory data is preprocessed locally to optimize communication power, but can be further processed using analytic engines in the cloud for better decision making and remote monitoring and control. This layer can be embedded in the above application layers and hosted in the cloud in a typical Agri-IoT ecosystem.
Network Management Layer: This discovers, connects, and translates devices over a network, and coordinates with the above application layers. This layer contains the BS, which interfaces the resource-constrained WSN and cloud information network. By convention, the WSN sublayer must utilize low-power communication standards such as Zigbee, SigFox, LoRa, BLE, Z-Wave, SigFox, and IEEE P802.11ah (low-power Wi-Fi), while the BS-to-Cloud connectivity can be achieved via the traditional cellular networks, satellite networks, Wi-Fi, LAN, and WAN, LoRa, among others. Unlike classic IoT, Agri-IoT requires that the BS-to-Cloud connectivity utilize low-power communication standards. Also, since every communication standard for the resource-limited WSN sublayer comes with unique resource specifications and design tradeoffs between power consumption, routing architectural constraints, and bandwidth [
4,
14,
17], the best connectivity option must be selected to achieve the desired application goals. Consequently, the stated WSN-based connectivity technologies can be classified using several distinct parameters, such as energy consumption rates, uplink/downlink data rates, packet size, SN-count per BS (gateway), network routing topology, the SNs’ sensing range, the SNs’ transmitter/receiver power, frequency bandwidth, channel width, etc. (refer to the right portion of
Figure 8).
Physical/Perception/Things Layer: This layer refers to the field and all devices such as SNs, actuators, RFID tags, sensors, and edge devices that interact with the environment. This layer senses and collects the necessary information from the connected devices in the WSN sublayer to the BS. In Agri-IoT networks, the sampled microclimatic data can be processed and stored on the local BS, the cloud, or both. The activities in the cloud or application layers are beyond the scope of this tutorial.
2.2. Associated Hardware Components and Technologies Required in the Proposed Architectural Layers
To precisely model and design an Agri-IoT network of desired expectations (refer to
Figure 2) using the proposed architectural layers shown in
Figure 8, the knowledge of the principal components and technologies used in each of these layers, and how they interact and adapt for their intended functions is imperative. As depicted in the middle of
Figure 8, the Agri-IoT ecosystem is composed of the following core components/technologies:
Things: Things unit is the physical interface between the tracked/monitored asset and the BS or actuator controller, which aligns with the physical or perception layer. It comprises the monitored/tracked asset (for example, field, crop, or animal), the SNs, or the entire IoT devices making up the WSN (for example, SNs, actuators, IoT-enabled devices, WSNs, and other smart devices), the event sampling, and routing technology in the WSN. Since the SNs constituting this unit are resource-constrained, freely available communication standards such as Zigbee, BLE, Z-Wave, and IEEE P802.11ah (low-power Wi-Fi), are the most suitable for both SN–SN and SN–BS communications. The Things unit accesses the cloud/Internet via gateways (BS).
Gateway (BS): The BS interfaces the WSN out in the field and the applications situated in the cloud servers. This unit aligns with the network management and actuator control layer shown in the middle of
Figure 8. The WSN sublayer may have more than one BS(s), each with the capacity to handle most resource-demanding computational tasks besides actuation execution, network construction, scheduling of event sampling, and network supervision services. They may also allow bidirectional communication with the cloud/user and WSN. Similar to standalone IoT devices, the BS can be equipped with 4G/5G/LTE/NB-IoT, cellular-based, Wi-Fi, LoRaWAN, or wired ethernet communication technologies to interact with the cloud, and low-power communication standards such as LoRa, low-power Wi-Fi, SIGFOX, UMTS, BLE, and Zigbee (
Figure 8) to communicate with the sensor field. However, Agri-IoT networks require that both upper-layer and lower-layer communication technologies of the BS should be low-power, freely available, easy to deploy and manage, and platform-independent. The BS may preprocess or relay the raw data to the cloud for remote data processing. The BS(s) locations are strategically chosen to optimize network communication costs.
IoT Cloud: The Cloud unit aligns with the applications layer. It consists of an on-premises or remote server farm that hosts the applications layer, event data analytic engines, security protocols, robust IoT applications, user interface, and event database. The high resource-demanding data processing tasks are mostly executed by well-equipped cloud-hosted applications to manage and store huge amounts of data, provide monitoring and data analytical services, enable communication with devices, and manage information access. The merits of Edge computing can be exploited to ensure that large amounts of data are post-processed off-device to reduce the response times of the cloud.
User Interface: With the aid of a web or mobile app, the user or farmer can live-monitor the farm’s conditions and execute control actions. Additionally, a presentation or business intelligence layer may be added to coordinate the activities of non-technical business users through dashboards and reports rather than with the application layer itself.
2.3. Quality Expectations of Agri-IoT’s Architectural Layers
Although there is no unified, certified, and flexible Agri-IoT architecture layer, any suitable options deduced from the benchmarking architectures in
Figure 7 must satisfy certain quality requirements, including:
Simultaneous data acquisition, analysis, and control from many sensors or actuators.
Minimization of huge raw data transmissions via data aggregation techniques to maximize actionable information quality.
Provision of reliable network architecture that supports energy-efficient routing, stable connectivity, self-adaptability, fault-tolerance, operational simplicity/flexibility, platform independence, affordability, and location independence of Agri-IoT designs.
Support for automated/remote device management and updates.
Easy integration of each layer with existing applications and other IoT solutions via specified APIs.
Utilization of freely available, location-unrestricted, cheap, energy-efficient, and simple to deploy and manage by non-experts [
4,
29] underlying communication technologies in the PHY and Network layers, as well as based on open standards to guarantee interoperability.
7. State-of-the-Art on Real-World, Canon WSN-based Agri-IoT Testbed Solutions
It is well documented that WSN-based Agri-IoT is the most reliable remedy for mitigating the negative impacts climate change has had on agricultural production, for which many architectural designs and testbed prototypes have been proposed [
12,
37]. In addition, since the autonomous, resource-constrained SNs in Agri-IoT are expected to operate without post-deployment maintenance checks, the issues of FM, power optimization, and self-organization during SN design and network deployment cannot be ignored in existing testbed solutions [
12,
121]. Essentially, the results from most research projects on Agri-IoT relied on simulation experiments [
1,
10,
14], which have retained the gap between the philosophy of this technology and the comprehension of its real-world behavior for a more accurate performance assessment. This section presents a systematic performance assessment of the few real-world WSN-based Agri-IoT testbed solutions currently based on the classic WSN-based IoT principles. To understand how the benchmarking realization testbeds of Agri-IoT in [
1,
10,
11,
14,
18,
19] fared in real-world operational conditions, the results from their respective performances are systematically evaluated and summarized in
Table 8. It was discovered that the current benchmarking testbed solutions in [
1,
10,
11,
14,
18,
19] are capital-intensive because they are reliant on fixed/location-restricted backbone infrastructures (see the middle of
Figure 4), too complicated to deploy and manage by even expert users, based on unrealistic indoor conditions which do not commensurate real-world environmental conditions, and based on the high- power-demanding centralized or flooding architectures which further complicate network manageability when up-scaled. A concise and systematic survey of these benchmarking real-world Agri-IoT networks and their flaws in the state of the art is summarized in
Table 8.
Additionally, it can be established from the comparative assessment of the benchmarking Agri-IoT testbeds in
Table 8 ([
10,
11,
18,
19]) that the embedded communication technology, event routing architecture, and the SNs’ power management are the core factors that made them capital-intensive and complicated to both experts and low-income farmers. Additionally, self-healing, reconfigurability, and adaptability mechanisms to faults were not deployed [
1,
14,
17], hence faulty and turbulent conditions could not be tolerated. Furthermore, since the battery-powered SNs rely on expensive Wi-Fi and cellular communication technologies that are not freely accessible at all locations, the SNs exhausted their battery supply a few days after deployment. Similarly, those that relied on ZigBee/ IEEE 802.15. 4 communication technologies with power-intensive 6LoWPAN or IPv6 protocols restricted the resulting network to drive on the problematic centralized or flooding architectures without any efficient FM techniques. As a result, these solutions used costly fixed IP infrastructural supports and the centralized routing architecture, making them practically impossible to manage as the networks scaled. This is why the SNs unstably exhausted their battery power and abruptly abridged network lifespans [
1,
10,
11,
14,
18,
19,
1].
Therefore, the freely available low-power wireless technologies (
e.g., LoRa, BLE, 5G, Z-wave, NB-IoT, and SigFox) that are founded on a suitable routing topology are the best candidates for making this ubiquitous application [
1,
16] cheap [
1,
20] and simple for all users. Thus, the cluster-based topology is more pivotal to addressing the above challenges of Agri-IoT [
10,
17] than the traditional cellular and WiFi technologies that are inaccessible in many farms, depending on their locations [
10,
20]. However, besides distance-power constraints, architectural support, and network manageability challenges, these freely accessible wireless communication technologies have specific limitations, which include:
ZigBee technology achieves the desired power-savings only when deployed in star or centralized topology [
14], and operates at its low-power distance range (10–100 meters) in line-of-sight mode depending on the environmental characteristics.
LoRa is limited to low density and fixed network sizes (non-scalable), low data rate, and low message capacity [
14]. It may require registration and expensive antennae, depending on its operation location.
SigFox supports a very low data rate and requires registration. LoRa and SigFox possess complex implementations because they both require specific modules to function and gateways.
WiFi, GPRS, cellular technologies, and NB-IoT are high power consumption standards and location-/architecture-restricted.
BLE has a short communication range but supports clustering architecture, which is the most optimal architecture for ensuring the best operational efficiency of WSN-based Agri-IoT deployments since this architecture allows cluster isolation and management.
Therefore, a research opportunity exists for a flexible, ubiquitous, realistic, energy-efficient, self-healing, simple, low-cost, cluster-based, and wireless outdoor-based testbed that consists of infrastructure-less, task-scalable, and wirelessly configurable experimental SNs and a BS. It should also be deployed, re-deployed, monitored, controlled, and managed by non-experts to operate stably throughout the entire crop-growing season.
8. Case Study: Cluster-Based Agri-IoT (CA-IoT) for Precision Irrigation
As earlier established in
Figure 2, the design and implementation of Agri-IoT networks are driven by unique critical factors, which are mainly determined by the associated routing architecture, communication technology, actuation management mechanisms, and environmental impacts. In the operation phase, these factors constitute the specific objectives in (
Figure 10, which the supervisory routing protocol must address in order to optimize performance efficiency and stability. As systematically established above, the LEACH-inherited cluster-based architecture has the most promising potential to address these technical challenges. It helps to attain high power optimization via communication distance and packet minimization, efficient network administration/adaptability, high event data quality through auto-FM, and local data quality management, as indicated in
Figure 10. So, this section presents a systematic analysis of how the merits of this architecture evolve in CA-IoT for precision irrigation use cases. Using the framework in
Figure 12, the cluster-based architecture was pre-examined to uncover how the fundamental Agri-IoT design requirements and goals presented in the reference frameworks in
Figure 9,
Figure 10, and
Figure 2 can unfold into realistic multi-parametric optimization metrics.
The conceptual architectural framework of the proposed network, as illustrated in
Figure 18, can be implemented using Arduino-based or Raspberry Pi(RPi)-based microcontrollers, BLE and LoRa for intra-cluster inter-cluster and BS–Cloud communications respectively, and DHT22/STEMMA soil moisture sensors for measuring the respective ambient and soil microclimatic parameters. Also, a unit cluster from
Figure 18 detailing the key network components of MNs, CH, BS, and the field-deployed precision irrigation system is shown in
Figure 19. It is assumed that the core units constituting the MNs, CH, and BS, as illustrated in
Figure 19, are optimally selected and designed after
Figure 2. Using
Figure 18 and
Figure 19 as the reference architectural frameworks for achieving our contextualized objectives, this section presents an in-depth systematic assessment and characterization of the scores of canon cluster-based routing protocols of conventional WSN-based IoT applications so that the desired MOO metrics can be appropriately deduced and adapted for the design of the associated routing for our case study.
8.1. Characterization of Canon Clustering-based Routing Protocols and Deduction of MOO Metrics
A systematic survey (refer to
Table 9) and characterization of LEACH-based routing protocols were conducted using the clustering process, CH features, and cluster features, as indicated in
Figure 20, in order to conceive the core MOO metrics for the proposed CA-IoT network framework. The clustering process, CH features, and cluster features define the performance optimalities and the quality of the sampled data of the resulting architecture.
As depicted in
Figure 20a, the cluster features define the underlying connectivity issues, such as cluster quality indices (thus, cluster count, cluster size) and intra-cluster, and inter-cluster communication types (thus, single-hop or multihop or both) [
23,
24]. From the network design viewpoint, the cluster quality depends on the optimality of the CH count and cluster sizes, which in turn rely on the core design parameters, such as the spatial density and uniformity of the deployed nodes, the specification of the wireless communication standard, the routing architecture, and the size of the network [
48]. Since the deployment of SNs in a typical Agri-IoT can be controlled, the stipulated cluster quality properties can be optimized to resolve connectivity issues in
Figure 20b. In a randomly deployed field, these cluster quality parameters can be optimized using pairing-based SN duty-scheduling mechanisms [
9,
12].
Secondly, the CH features can be static, mobile, or role-rotated in both homogeneous or heterogeneous networks [
9,
12] based on the SNs’ resource hierarchy. Additionally, the CHs can be assigned different tasks, such as data aggregation, FM, coordinating network reconfiguration or duty-cycling, and network maintenance, depending on their resource capacities and network requirements. This case study is based on static SNs and the distributed network construction approach (see references in [
9,
12,
34,
122,
123,
124,
125,
126,
127,
128]), where the SNs locally manage the entire clustering process, and a CH is elected without the entire network’s information.
As shown in
Figure 20a, the clustering process can be characterized by the clustering method/network type (thus, centralized or distributed), the CH selection method, reclustering or network adaptability to topological or scalable conditions, and the complexities (thus, control message and computational complexities) of the entire network operation cycle. Unlike the static approach with fixed CH, the adaptive clustering approach selects CH based on the current network conditions and rotates this role. However, both approaches can incorporate self-reclustering techniques to self-heal SN-out-of-service faults. Data outlier faults can be best detected and corrected using threshold-based decision theory or spatial correlation methods with the least complexities. Due to the large-scale and high deployment densities of WSN-based Agri-IoT, the distributed clustering process is more suitable for enhancing local FM, scalability, network management, and power optimization than the centralized approaches [
38,
48].
Generally, CA-IoT network can be optimized by formulating the deduced optimal decision metrics in
Figure 20a into a MOO framework and multihop routing model in order to provide the guidelines for the design of the WSN sublayer of Agri-IoT. From the comparative evaluations of
Figure 10 and
Figure 20a, a taxonomy of MOO metrics for designing an efficient WSN-based CA-IoT network is proposed in
Figure 20b. To enhance the clarity of the state-of-the-art on cluster-based protocols and justify the need for the proposed MOO metrics, a comparative summary based on the characterization parameters is presented in
Table 9.
8.2. CH Election Techniques
A CH selection process is very critical to the resulting network’s performance efficiency. Besides centralized networks and the computationally expensive fuzzy-based clustering approaches [
137,
138], the efficiencies of all LEACH-inherited protocols are mainly dependent on their CH selection techniques [
48,
50]. Therefore, the correct estimation of the cluster quality metrics (
i.e., CHs count, and cluster size) is pivotal in attaining the objectives in
Figure 10. With the aid of nodes’ residual energy and location metrics, the optimal CH-count and cluster size can be preset before network deployment. Currently, these metrics are randomly selected using a probabilistic approach in LEACH-inherited protocol [
9,
21] or derived using a deterministic or an attribute-based method [
48,
139]. However, the probabilistic clustering, such as the LEACH-inherited protocols, is expected to perform better in terms of network lifespan, minimal clustering overhead, improved connectivity, network/coverage stability, low latency, collision-free routing, load balancing, high network stability span, and algorithmic simplicity if the optimal CH-count predefined correctly [
140]. However, the CH-count is randomly predefined in these protocols [
9,
21], which underminds CHs stability and the resulting architecture’s optimality. This challenge can be addressed via common CH selection metrics including Euclidean distance, intra-cluster/inter-cluster communication costs, energy harvesting capacities, and probabilistic factors. To date, the related attempts in [
50,
122,
141,
142,
143] only relied on SNs’ residual energy and location information to re-elect CHs after the initial CH-count is defined, which cannot be ideal for WSN-based Agri-IoT.
For instance, an active SN in a particular round decides whether or not to become a CH by choosing a random number (
) ranging between 0 and 1 and comparing the number with a specified threshold
. A node, therefore, becomes a CH for that round if
, where
is expressed as:
where
is the desired percentage of CHs or CH count per round, and
G is the SNs that have not been a CH in the previous
rounds.
The authors in [
130] proposed a three-layered LEACH (TL-LEACH) that operates in three functional phases: CH election, MN recruitment, and data transfer to enhance the energy efficiency of LEACH. Their first-level CH election approach modified Eq. (
1) into an enhanced threshold
, which is expressed as:
where
p is the CH count,
r is the current round number, and
G is the SNs that have not been a CH in the previous
rounds. The second-level CHs are selected from the first-level CHs based on the shortest distance to the BS to function as aggregated packet forwarders or relay CHs (RCHs).
The authors in [
131] introduced energy (
) and distance (
) attributes into Eq. (
1) to improve the load-balancing merit of LEACH. The resulting
is expressed as:
Multihop routing via relay CHs (RCHs) was recommended for distant-CHs in the future scope of [
131].
In the LEACH presented with a distance-based thresholds (LEACH-DT) algorithm in [
132], the probability of becoming a CH depends on the relative distance between a node and the BS. This algorithm differs from the LEACH algorithm because the desired percentage of CHs (
) is pre-defined using Eq. (
5), while the threshold
is expressed as:
Note that the terms retain their usual definitions, namely:
where
The variable depicts the distance between node i and the BS, and and are the average residual energies in CHs and non-CHs, respectively. The authors further established the need for a multihop routing approach in simulations and real-world WSNs to validate the countless theoretical propositions and benefits.
In the decentralized energy-efficient hierarchical cluster-based routing algorithm (DHCR) [
134], SNs compete to become CHs. First, the BS broadcasts a trigger message at a specific range. The receiving nodes then compete to become a CH by disseminating a new message containing their residual energies and distances from the BS. Using this information, a neighboring node
i within the target range receives the message and calculates its
as:
where
and
are the residual and initial energy levels of node
i, respectively;
is the distance between node
i and the BS and
a and
b are real random values between 0 and 1 such that
. The value of
of node
i and its neighbors are compared, and the node with the highest
value is selected as the CH. A first-level CH broadcasts its residual energy, neighboring node count, and distance from the BS via a specific route. The next-level CHs receive the information and similarly repeat the procedure to ensure that every node determines a redistributor CH to the BS at the same time. A redistributor CH has more energy and fewer neighbors (neighboring degrees).
However, the Hamilton energy-efficient routing protocol (HEER) [
135] creates an entire cluster of nodes, aggregates data, and transmits them to the BS via a Hamiltonian path that has been created by the entire cluster of nodes and controls the cluster size by selecting one node as the CH using the probability function
p, which can be expressed as:
where
is the size of every node, and
is the maximum size of a frame. The HEER protocol creates the clusters only once in the first round based on LEACH, and role-rotates the CHs per the energy on the Hamiltonian path after a determined period.
Similarly, the two-phased EAMR protocol [
136] randomly preselects the CH. A CH also selects its closest CH as its redistributor CH. The clusters are static over the entire network lifetime, and the CH role rotates randomly within the clusters according to a cluster replacement threshold. The new CH inherits the redistributor role if the old CH had one. Overall, since node location, residual energy, and sleep schedule are indispensable in the CH selection process, the CH selection methods proposed by the authors in [
9,
12,
37,
131,
144] are recommended WSN-based Agri-IoT applications.
8.3. Challenges of Existing MOO Frameworks and Recommended Future Works
As
Figure 9 and
Figure 10 illustrate, the performance efficiency of an infrastructure-less WSN-based Agri-IoT mainly depends on the embedded MOO remedies in the associated supervisory routing protocol [
12]. Several MOO frameworks have been researched since Agri-IoT networks are subjected to multiple design and operational constraints. A MOO framework is expected to formulate multiple objective functions from a set of MOO metrics to simultaneously optimize these multiple objectives, such as the maximal energy savings, highest connectivity, best latency, highest reliability, and balanced SN power depletion rates across the network. Although the MOO methods are the best candidates for Agri-IoT, the existing MOO solutions used in Agri-IoT are adopted from traditional WSN-based IoT without any contextual evaluation [
12,
16,
26]. Consequently, they have not fulfilled their intended purposes due to several technical challenges, including the following:
Therefore, there is an urgent demand for a realistic low-power MOO framework for CA-IoT networks that is founded on the core WSN design metrics and MOO taxonomy metrics in
Figure 10 and the top of
Figure 20, respectively. The following section assesses how evaluations and deductions evolve in a typical event sampling and routing protocol in a CA-IoT network for precision irrigation system management.
11. Conclusion and Future Works
This tutorial presented: (1) a systematic overview of the fundamental concepts, technologies, and architectural standards of WSN-based Agri-IoT; (2) an evaluation of the technical design requirements of a robust, ubiquitous, self-healing, energy-efficient, adaptive, and affordable Agri-IoT; (3) a comprehensive survey of the benchmarking FM techniques, communication standards, routing protocols, MMAC protocols, and WSN-based testbed solutions; and (4) an in-depth case study on how to design a self-healing, energy-efficient, affordable, adaptive, stable, and cluster-based WSN-specific Agri-IoT from a proposed taxonomy of MOO metrics that can guarantee optimized network performance. Furthermore, this tutorial established new taxonomies of faults, architectural layers, and MOO metrics for CA-IoT networks. Using the open technical issues, it recommended application-specific requirements of Agri-IoT, general design expectations, remedial measures, and evaluated them in CA-IoT for precision irrigation in order to optimally exploit the proposed MOO metrics in a typical CA-IoT’s design in both simulation and real-world deployment scenarios. Overall, this tutorial can serve as a new reference document for the IoT community and Agri-IoT designers, since it adequately examined all critical aspects of WSN-based Agri-IoT networks from theoretical modeling to real-world implementation.
Figure 1.
Season Failure Probability-2014 [
4] Depicting the Extent of Climate Change Impact on Africa’s Farmlands.
Figure 1.
Season Failure Probability-2014 [
4] Depicting the Extent of Climate Change Impact on Africa’s Farmlands.
Figure 2.
Generalized Design Expectations of WSN-based Agri-IoT Technology.
Figure 2.
Generalized Design Expectations of WSN-based Agri-IoT Technology.
Figure 3.
Conceptual Framework: Agri-IoT-Based Farm Monitoring and Control Cycle.
Figure 3.
Conceptual Framework: Agri-IoT-Based Farm Monitoring and Control Cycle.
Figure 4.
Generalized Agri-IoT Framework Consisting of: Field Layout Overview of Agri-IoT Framework (a), Sample of Classic Agri-IoT in the State-of-the-Art (b), and Key Components of a SN or a BS (c).
Figure 4.
Generalized Agri-IoT Framework Consisting of: Field Layout Overview of Agri-IoT Framework (a), Sample of Classic Agri-IoT in the State-of-the-Art (b), and Key Components of a SN or a BS (c).
Figure 5.
Generalized Taxonomy of IoT Applications.
Figure 5.
Generalized Taxonomy of IoT Applications.
Figure 6.
The Roles of Agri-IoT in Smart Farming with Specific Use-Cases.
Figure 6.
The Roles of Agri-IoT in Smart Farming with Specific Use-Cases.
Figure 7.
Different Architectural Layers in the State-of-the-Art of IoT Ecosystem.
Figure 7.
Different Architectural Layers in the State-of-the-Art of IoT Ecosystem.
Figure 8.
Proposed Agri-IoT Architectural Layers with Core Components of Agri-IoT Ecosystem, and the "Things" Taxonomy.
Figure 8.
Proposed Agri-IoT Architectural Layers with Core Components of Agri-IoT Ecosystem, and the "Things" Taxonomy.
Figure 9.
Principal Design Factors for Agri-IoT Networks.
Figure 9.
Principal Design Factors for Agri-IoT Networks.
Figure 10.
Expected Design Objectives and Strategies of WSN-based Agri-IoT Routing Protocols.
Figure 10.
Expected Design Objectives and Strategies of WSN-based Agri-IoT Routing Protocols.
Figure 11.
Taxonomy of WSN-based Routing Protocols of Agri-IoT.
Figure 11.
Taxonomy of WSN-based Routing Protocols of Agri-IoT.
Figure 12.
Sample Network Architectures: Centralized-Data-Centric, Cluster-based, and Graph/Flooding-based Architectural Frameworks of WSN sublayer.
Figure 12.
Sample Network Architectures: Centralized-Data-Centric, Cluster-based, and Graph/Flooding-based Architectural Frameworks of WSN sublayer.
Figure 13.
Proposed Functionality-based MAC Classification Framework.
Figure 13.
Proposed Functionality-based MAC Classification Framework.
Figure 14.
Fault-Error-Failure Cycle [
73].
Figure 14.
Fault-Error-Failure Cycle [
73].
Figure 15.
Faults in the WSN sublayer of Agri-IoT: Sources and Fault Propagation Model.
Figure 15.
Faults in the WSN sublayer of Agri-IoT: Sources and Fault Propagation Model.
Figure 16.
Classification of Faults in the State-of-the-Art and Proposed Fault Taxonomies for WSN-based Agri-IoT.
Figure 16.
Classification of Faults in the State-of-the-Art and Proposed Fault Taxonomies for WSN-based Agri-IoT.
Figure 17.
FM Framework in WSN Sublayer of Agri-IoT.
Figure 17.
FM Framework in WSN Sublayer of Agri-IoT.
Figure 18.
Conceptual Architectural Framework of the Proposed CA-IoT for Precision Irrigation Management.
Figure 18.
Conceptual Architectural Framework of the Proposed CA-IoT for Precision Irrigation Management.
Figure 19.
CA-IoT Use Case Cluster Illustrating the Key Network Components: MNs, CH, and BS.
Figure 19.
CA-IoT Use Case Cluster Illustrating the Key Network Components: MNs, CH, and BS.
Figure 20.
Characterization of Cluster-based Networks and Deduced Taxonomy of MOO Metrics for Optimizing Agri-IoT Networks.
Figure 20.
Characterization of Cluster-based Networks and Deduced Taxonomy of MOO Metrics for Optimizing Agri-IoT Networks.
Figure 21.
Proposed Operation Cycle for Designing our CA-IoT Network’s Routing Protocol.
Figure 21.
Proposed Operation Cycle for Designing our CA-IoT Network’s Routing Protocol.
Table 1.
Comparison of SN and BS.
Table 1.
Comparison of SN and BS.
Network Participant |
Power Source |
Communication Technologies |
Controller Type |
Processor/Memory Requirements |
Requires Sensors |
SN |
Mostly battery-powered |
Mostly relies on low-power, short ranged standards such as BLE, LoRa, SigFox, and ZigBee for on-field communication |
Can be Arduino-based, or Raspberry Pi (RPi)-based, etc. |
Low processing and storage powers but based on SN roles |
Yes |
BS |
Can be battery-powered but mostly use a more reliable power supply |
Mostly communicate with IoT cloud via fixed line, Wi-Fi, cellular technologies, and the WSN via the low-power standards, e.g., BLE, LoRa, SigFox, ZigBee, LoRa-based Satellite, etc. |
Can be RPi or Arduino-based or a PC. |
Requires high memory and processing powers |
No |
Table 2.
Comparison of WSN, IoT, and Agri-IoT Technologies.
Table 2.
Comparison of WSN, IoT, and Agri-IoT Technologies.
Characteristics |
WSN Technology |
IoT Technology |
Agri-IoT Technology |
Internet Connectivity |
SNs have no direct connection to the Internet, always via a BS/router/gateway if necessary |
Nodes directly send sampled data to the Internet |
SNs’ Internet connectivity can be either direct or via a BS |
Critical Design factors/ Expectations |
Application-specific |
Security, Interference, linking fleet |
Power optimization, routing architectural support, fault tolerance, on-site auto-actuation demand, and self-adaptability to network dynamisms |
Deployment Density |
Application-specific |
Moderate |
High |
Power Supply Constraints |
Application-dependent |
Application-specific |
Compelled to drive on battery power |
On-site Electricity and Internet Coverage |
May be possible |
Required |
Mostly inaccessible |
Implementational Routing Architecture |
centralized or flooded |
Mostly centralized |
Contextualized cluster-based but inadequately researched |
Communication Technology |
Application-specific |
May use high-power standards such as Wi-Fi, cellular-based, Satelite, fixed-line, etc. |
Requires low-cost low-power standards such as BLE, LoRa, SigFox, ZigBee, etc. that support cluster-based architecture |
Users’ Expectations |
Performance stability |
Performance stability |
Affordability, autonomous performance stability, location-independence, simple to deploy and operate by non-experts, supportive of large-scale farm management, and based on freely available communication technologies that do not require licensing. |
Network Type |
Data-centric |
Use information network directly |
Mostly data-centric |
Basic Components |
Resource-constrained SNs, BS or Sink Node |
May include smartphones, PCs, WSN, BS, Internet, IoT Cloud with data analytic tools, and the user interface app. |
WSN, BS, IoT-cloud with application-defined user apps and data analytical engines |
Security and Privacy |
Medium |
High |
low |
On-site Actuation Required? |
Not always |
No |
Yes |
Network Participant mobility during Operation |
Usually static |
Mobile |
Application-specific |
Table 3.
Wireless Spectrum with the Core Communication Platforms/Applications.
Table 3.
Wireless Spectrum with the Core Communication Platforms/Applications.
Frequency Band |
Applications |
Licensed Band |
|
0-20 MHz
|
AM Radio |
86MHz-108MHz
|
FM Radio |
470MHz-800MHz
|
TV band |
850MHz-1900MHz
|
Cellular-based: GSM/3G/4G/5G/LTE |
Around 3.5GHz
|
Satelite Comm. |
Unlicensed Band |
|
863MHz-928MHz
|
LoRa, LoRaWAN, SigFox |
|
Legality location-dependent: e.g., |
|
915MHz (Australia & North America), |
|
865MHz to 867MHz (India), 923MHz (Asia) |
Around 2.4GHz
|
Wi-Fi, BLE, ZigBee,Classic Bluetooth |
Around 5GHz
|
Wi-Fi |
Table 4.
Comparison of Common Communication Platforms of the WSN Sublayer of Agri-IoT.
Table 4.
Comparison of Common Communication Platforms of the WSN Sublayer of Agri-IoT.
Platform/ |
Network |
|
|
Transmission |
Frequency |
DataRate/ |
Network |
Energy |
Topology |
Standard |
Size |
|
|
Range(Outdoor) |
Band |
latency |
Type |
Consumption |
|
BLE/ IEEE 802.15.1 [6] |
Application- |
3-10 |
|
10-50m
|
2.4GHz
|
1Mbps/6ms
|
PAN,WSN |
Very Low |
Star, mesh |
|
-defined |
|
|
|
|
|
|
|
|
Bluetooth Classic/ IEEE 802.15.1 [5] |
7 |
215 |
|
10-100m
|
2.4GHz
|
1-3Mbps/100ms
|
PAN |
High |
Scatternet |
WiFi/ IEEE 802.11 a/c/b/d/g/n [7] |
255 |
800-835 |
162 |
|
5-60GHz
|
1Mb/s -7Gbps/50ms
|
LAN |
High |
Point-to-hub |
LoRaWAN/LoRaWAN R1.0 [6,8] |
|
25-100 |
|
|
868/900MHz
|
0.4-100Kbps/NA |
WAN |
Very Low |
Star-stars |
Sigfox [2,6] |
Undefined |
122 |
|
|
200kHz
|
100-600bps/NA |
PAN |
Low |
Star |
ZigBee/IEEE 802.15.4 [2,23] |
64000+ |
36.9-100 |
77 |
10-20m
|
2.4GHz
|
20-250Kbps/(20-30)ms
|
PAN, WSN |
Low |
P2P,tree,star,mesh |
NB-IoT,LTE/2G-GSM,4G-LTE [2,4] |
1000 |
200-560 |
80 |
|
2.4GHz
|
200Kb/s-1Gbps/1s
|
WAN |
Medium |
Cellular system |
//IEEE 802.15.4 [23] |
64000+ |
8.9-36.9 |
35.28 |
|
2.4GHz
|
20-250Kbps/40ms
|
PAN |
Low |
P2P,tree,star,mesh |
XBee PRO [24] |
64000+ |
36.9-63 |
|
|
900MHz
|
20-250Kbps/40ms
|
PAN, WSN |
Low |
P2P,tree,star,mesh |
Jennic JN5121/IEEE 802.15.4 |
64000+ |
100 |
|
|
2.4GHz
|
20-250Kbps/30ms
|
PAN, WSN |
Low |
P2P,tree,star,mesh |
RFID/ISO 18000-6C [4,29] |
Undefined |
3000 |
unspecified |
|
860-960MHz
|
40-160Kbps/45ms
|
PAN |
Low |
Star |
Table 5.
Comparison of Some Cardinal Hierarchical WSN-based Routing Protocols for Agri-IoT in State-of-the-Art.
Table 5.
Comparison of Some Cardinal Hierarchical WSN-based Routing Protocols for Agri-IoT in State-of-the-Art.
Protocol |
Topology |
Strength |
Weakness |
Suitability: Low-power |
|
|
|
|
WSN sublayer of Agri-IoT |
LEACH and LEACH-inherited [9,12,21] |
Tree or Cluster-based |
|
|
Suitable (optimal cluster quality yet required) |
RPL and RPL-Inherited [15] |
Graphical |
High adaptability,
High robustness,
Minimized control messages,
Suitable for small-scaled, power-sufficient networks
|
High energy wastages,
High storage requirements,
Low reliability,
High congestion rates,
Unsuitable for large-scale turbulent networks,
More resource-demanding than AODV and LEACH-based methods [ 51, 52]
|
Unsuitable (high resource-demanding underlying technology,6LoWPAN, and routing tables) |
AODV and AODV-inherited [13] |
Mostly graphical |
|
High control messages,
High energy wastages [ 28],
High-resource-demanding
|
Unsuitable (extremely high control message complexities during route construction and maintenance) |
Table 6.
Summary of State of the Art on Duty-cycle and CAM MMAC-Protocols.
Table 6.
Summary of State of the Art on Duty-cycle and CAM MMAC-Protocols.
Name |
Main Task |
Application |
Weakness |
Approach |
Overhead |
Sync/ Async |
S-MAC, T-MAC, DS-MAC[54,55] |
DCO |
Event-driven with long idle listening times, collision-prone. |
High PC, complexity, latency |
Contention-based, distributed MAC |
RTS, CTS, ACK, SYNC |
Sync |
X-MAC [56] |
DCO |
High energy savings, throughput, collisions, delays |
high complexity, higher PC, High collisions |
Contention-based, distributed MAC |
Preamble |
Async. |
LA-MAC [57] Inherits X-MAC [56] |
DCO |
More energy savings than X-MAC, throughput, scalability collisions, low delays |
High complexity, weak collision control measures |
Contention-based, distributed MAC |
Preamble |
Async. |
B-MAC [58] |
DCO |
Delay-tolerant, high energy savings, throughput, DDR more than S-MAC, |
High complexity, weak collision control measures, low throughput |
Contention-based, distributed MAC (CSMA) |
Preamble length |
Async. |
(PEDAMACS) [59] |
DCO with collision avoidance |
Event-driven, energy-saving |
High computational complexity, impracticable |
Schedule-based, centralised MAC |
RTS, CTS, ACK, SYNC, learning |
Tight Sync. |
PW-MAC [60] |
DCO |
Low delay, long idle time |
High complexity |
Contention-based, distributed MAC |
Beacon |
Async. |
cluster-based time synchronization [61] |
DCO |
High energy savings |
High computational complexity |
Schedule-based, cluster-based, distributed MAC |
Schedule, CHs’ formation |
Tight Sync. |
LEACH [62] |
DCO and CAM |
Periodic sampling surveillance, energy balance, savings |
High complexity, weak collision control measures |
Schedule-based, cluster-based, distributed MAC |
Schedule, CHs’ selection |
Tight Sync. |
PRIMA [63] |
DCO and CAM |
Periodic sampling/ surveillance, balanced energy-savings |
High complexity, weak collision control measures |
Schedule-based, cluster-based, distributed MAC |
Schedule, CHs’ selection |
Tight Sync. |
WiseMAC [64] |
DCO |
High energy-savings, collision, hidden terminal problem, poor duty schedule |
high complexity, weak collision control measures, high PC |
Hybrid, distributed MAC |
Long wake-up preamble |
Sync. |
Advanced WiseMAC [65] |
DCO |
Higher energy savings than WiseMAC, collision, hidden terminal problem |
high complexity, weak collision control measures, poor duty schedule |
Hybrid, distributed MAC |
Shorter wake-up preamble than WiseMAC |
Sync. |
WideMAC [66] |
DCO |
wider duty-cycle ranges, aperiodic or periodic Tx, higher energy savings, low memory requirements |
Weak collision control measures |
Hybrid, distributed MAC |
Preamble but short |
Sync. |
EM-MAC [67] |
CAM |
Heavy traffic, delay-tolerant, hidden terminal problem |
Prediction accuracy depends on the accuracy pseudorandom function |
Schedule-based, predictive-based, dynamic CAM, distributive MAC |
Initial preamble |
Async. |
MCAS-MAC [68] |
CAM |
High energy savings, latency, low idle listening |
Energy efficiency decreases with high traffic densities (high DDR) |
Schedule-based, distributed MAC |
Preamble |
Async. |
AMMAC [69] |
CAM and DCO |
High energy savings, DDR |
Time drift will affect accuracy |
Contention-based, distributed MAC |
Requires asynchronous modifications of duty-cycles |
Async. |
LL-MCLMAC [70] |
CAM |
Improved end-to-end delay and throughput, low traffic with two time-slots |
Data Tx on same control channel, Susceptible to co-channel or adjacent channel interference |
Semi-dynamic schedule-based, distributed MAC |
Common control channel notification |
Async. |
MC-LMAC [71] |
CAM |
Scalable WSNs, collision avoidance |
High delays due to dynamic channel switching |
Dedicated channel control, dynamic channels switching, schedule-based, distribute d MAC |
Common control channel notification |
Async. |
Table 7.
Comparative Summary of FM Schemes for WSN-based IoT Networks.
Table 7.
Comparative Summary of FM Schemes for WSN-based IoT Networks.
Author/Year |
Root Faults? (i.e., Data Outliers & SN-Out-of-Service) |
FM Architecture |
Unrealistic Assumptions |
Energy-saving (FA)? |
FT? |
High Control Message Complexity |
Stand-alone? |
[79] (2013) |
Yes, both |
Cluster-based |
All SNs have the same lifetime, SNs record the same sensory data regardless of location |
× |
✓ |
High |
× |
[96] (2016) |
Partial: data outliers |
Centralized |
SNs have binary sensing outputs |
✓ |
× |
Low |
✓ |
[81] (2015) |
Partial: data outliers |
Distributed |
All fault-free sensors measure the same physical value at any instant of time, while the faulty sensors measure different physical values |
✓ |
× |
Moderate |
✓ |
[107] (2006) |
Partial: SN-out-of-service |
Distributed |
All SNs must have enough Neighbors |
× |
✓ |
High |
✓ |
[76] (2009) |
Partial: SN-out-of-service |
Distributed |
SNs must have unvarying detected initial status |
× |
✓ |
High |
✓ |
[78] 2016 |
Partial: SN-out-of-service |
Distributed |
SNs must have the same initial status and a predefined number of neighbors |
× |
✓ |
High |
✓ |
[101,102,103] (2004, 2005, 2005) |
Partial: SN-out-of-service |
Distributed |
All SNs have the same error detection probability, all neighboring nodes of a SN have identical levels of accuracy regardless of distance |
× |
× |
High |
✓ |
[104] (2009) |
Partial: data outliers |
Distributed |
SNs have binary sensing outputs. |
× |
✓ |
High |
✓ |
[108] (2014) |
Partial: data outliers & SN-out-of-service |
Centralised |
Silent on assumptions |
× |
No |
Low |
✓ |
[105] (2008) |
Yes: transient faults |
Distributed |
All neighboring nodes have same transmission range and reading values. |
× |
× |
High |
✓ |
[109] (2016) |
Partial: SN-out-of-service |
Distributed |
Silent on assumptions |
× |
× |
Moderate |
✓ |
[112] (2015) |
Partial: data outliers |
Distributed |
Silent on assumptions |
✓ |
✓ |
Low |
✓ |
[113] (2009) |
Partial: SN-out-of-service |
Distributed |
All nodes must have identical measurements, a quadrant must have the same number of SNs |
× |
✓ |
High |
✓ |
[97] 2014 |
Partial: SN-out-of-service |
Centralised |
Based on historical network data: assumes all SNs are healthy initially to get training data. |
× |
× |
Moderate |
✓ |
[98] 2016 |
Partial: SN-out-of-service |
Centralised |
Based on historical network data: assumes all SNs are healthy initially to get training data. |
× |
× |
Moderate |
✓ |
[99] 2015 |
Partial: SN-out-of-service |
Centralised |
Silent on assumptions |
× |
× |
Moderate |
✓ |
[114] 2018 |
FT protocol |
Distributed |
Assumed centralised BS |
✓ |
✓ |
High |
✓ |
[115] 2017 |
Effects: network failure |
Distributed |
All SNs are homogeneous in terms of energy, communication, and processing capabilities |
× |
× |
High |
✓ |
[100] 2018 |
Partial: SN-out-of-service |
Centralised |
All faulty SNs must have at least a sleeping node in its proximity |
× |
✓ |
Moderate |
✓ |
[116] 2018 |
Partial: SN-out-of-service |
Distributed |
Silent on assumptions |
✓ |
✓ |
High |
✓ |
[117] 2016 |
Partial: SN-out-of-service |
Distributed |
All faulty SNs must have at least a sleeping node in its proximity |
× |
✓ |
Moderate |
✓ |
[118] 2013 |
Partial: SN-out-of-service |
Distributed |
Silent on assumptions |
× |
× |
Moderate |
✓ |
[119] 2016 |
Partial: data outliers |
Distributed |
Silent on assumptions |
✓ |
✓ |
Moderate |
✓ |
Table 8.
Comparative Analysis of WSN-based Agri-IoT Testbed Solutions.
Table 8.
Comparative Analysis of WSN-based Agri-IoT Testbed Solutions.
Author/Deployment Type |
Testbed Objective |
Comm. Tech& Architecture |
Weaknesses |
[10] (Outdoor) |
Disease control |
IEEE 802.15.4 /centralized, flooding |
Relied on a fixed support system, expensive, power-inefficient, location-restricted |
[11] (Outdoor) |
Precision farming, to gather real-world experiences |
ZigBee, Mica2 clones hardware and TinyOS software /centralized, flooding |
Relied on a fixed support system, expensive, power-inefficient, location-restricted, no single measurement was achieved due to high network complexity |
[18] (Indoor) |
Data outlier detection and decision support system for precision irrigation testbeds |
ZigBee/flooding-based |
Results based on 3 SNs under unrealistic indoor conditions |
[19] (Indoor) |
Latency improvement |
Fog computing, 6LoWPAN, 6LBR, and WiFi-based /centralized, flooding |
Capital-intensive, energy-inefficient, high complexity, location-restricted |
[1] (Indoor and Outdoor) |
Gather real-world deployment experiences |
ZigBee /centralized, flooding |
Result focused on mere observation, not real-world deployment scenarios. |
Table 9.
Comparative Summary of Agri-IoT- Applicable Clustering-based Routing Protocols using Characterization Parameters.
Table 9.
Comparative Summary of Agri-IoT- Applicable Clustering-based Routing Protocols using Characterization Parameters.
Protocol/Year |
Hierarchy |
DR-model |
Clustering |
Comm. type |
Objective |
CH Selection |
Cluster |
SN Mobility |
SN Type |
CH Role |
Constant Time |
|
|
|
Method |
|
|
Method |
Size |
|
|
Rotation |
Complexity |
LEACH,2002 [21,48] |
2-level |
Time-driven |
Decentralized |
Intra: Single-hop |
Max. WSN lifespan |
random |
uncontrolled |
Static |
Homogeneous |
✓ |
× |
|
|
|
|
Inter: single-hop |
|
|
|
|
|
|
|
SEP,2004 [129] |
2-level |
Time-driven |
Decentralized |
Intra: single-hop |
WSN stability pan |
Random |
uncontrolled |
Static |
Heterogeneous |
✓ |
× |
|
|
|
|
Inter: single-hop |
|
|
|
|
|
|
|
TL-LEACH,2007 [130] |
3-level |
Time-driven |
Decentralized |
Intra: Single-hop |
Data Aggregation |
Attribute-based |
uncontrolled |
Static |
Homogeneous |
✓ |
× |
|
|
|
|
Inter: Multihop |
|
|
|
|
|
|
|
PECRP,2009 [131] |
multilevel |
Time-driven |
Hybrid |
Intra: Single-hop |
Max. WSN lifespan |
Random |
controlled |
Static |
Homogeneous |
✓ |
× |
|
|
|
|
Inter: Multihop |
|
Attribute-based |
|
|
|
|
|
LEACH-DT,2012 [132] |
3-level |
Time-driven |
Decentralized |
Intra: single-hop |
Max. WSN lifespan |
Random |
uncontrolled |
Static |
Homogeneous |
✓ |
× |
|
|
|
|
Inter: single-hop |
|
Attribute-based |
|
|
|
|
|
EESAA,2012 [9] |
2-level |
Time-driven |
Decentralized |
Intra: Single-hop |
Max. WSN lifespan |
Random |
uncontrolled |
Static |
Homogeneous |
✓ |
✓ |
|
|
|
|
Inter: single-hop |
|
Attribute-based |
|
|
|
|
DEEC,2014 [133] |
2-level |
Time-driven |
Decentralized |
Intra: single-hop |
WSN stability pan |
Random |
uncontrolled |
Static |
Heterogeneous |
✓ |
× |
|
|
|
|
Inter: single-hop |
|
|
|
|
|
|
|
DHCR,2015 [134] |
multilevel |
Time-driven |
Decentralized |
Intra: Single-hop |
Min. Control messages |
Random |
controlled |
Static |
Homogeneous |
✓ |
✓ |
|
|
|
|
Inter: Multihop |
Max. WSN lifespan |
Attribute-based |
|
|
|
|
|
HEER,2016 [135] |
multilevel |
Time-driven |
Decentralized |
Intra: Multihop |
Max. WSN lifespan |
Random |
controlled |
Static |
Homogeneous |
× |
× |
|
|
|
|
Inter: single-hop |
|
Attribute-based |
|
|
|
|
|
S-BEEM,2017 [34] |
2-level |
Time-driven |
Decentralized |
Intra: Single-hop |
load balancing |
Random |
controlled |
Mobile BS |
Homogeneous |
✓ |
✓ |
|
|
|
|
Inter: Multihop |
|
|
|
|
|
|
|
EAMR,2018 [136] |
multilevel |
Time-driven |
Decentralized |
Intra: Single-hop |
Min. Control messages |
Random |
controlled |
Static |
Homogeneous |
✓ |
✓ |
|
|
|
|
Inter: Multihop |
max. WSN Lifespan |
Attribute-based |
|
|
|
|
|