## 4 Proposed MCA-IoT Design
### MCA-IoT Supervisory Software Development Phases and Implementation  
Following the hardware assembly, an iterative lean technology development approach, as illustrated in Figure 11, was employed. This method involved analyzing the system's  
Figure 10: A 4-cluster schematic diagram of the proposed multihop CA-IoT framework. expected performance metrics, developing custom-built prototypes, evaluating their performance against desired metrics, and iteratively refining the prototypes. The proposed event-routing protocol incorporates a cluster-based architecture, duty cycle, and fail-over scheduling for event sampling, data aggregation, and data transmission/reception. This protocol was developed using Python 3.7 within the Raspbian OS of the Raspberry Pi 3 B+. The design and implementation involved cluster formation processes, fault tolerance schemes from [10; 17], and cluster quality evaluation methods from [18]. Additionally, BLE 4.2 libraries and drivers for the ATSAMD10 Adafruit STEMMA soil sensor (i.e., I2C Capacitive Moisture Sensor), and DHT22 sensor were installed from Bluez and Adafruit, respectively. The software configuration followed the SN design steps from [10; 50], with the Bluey module installed for handling BLE device communications using code from the BlueZ project. The main software running on the BS, CHs, and MNs, as well as their modus operandi, as outlined in Figure 12, are detailed as follows:  
* The proposed MCA-IoT network utilizes three sets of distributed network management and sampling software: MN/client software, CH client/server software, and BS/gateway/server software. The operational steps and roles of the software programs for intra- and inter-cluster communications are illustrated in Figure 12. The MN software locally hosts a seesaw-embedded Bluetooth socket client in a Python 3.7 script for managing network construction, event sensing, BLE transceiver operational state moderation, and transmission of sampled data to the BS at specific corn tabelsots. This intra-cluster software, shown in Figure 12a, was designed using Bluetooth socket programming, the seesaw module, the BlueZ module, local time, built-in corntab -e in Python 3.7, and NTP from time.google.com. * A CH incorporates client and server codes within a single software package, enabling it to receive data from MNs (server) and distant CHs and to act as a client to the BS or RCHs. As shown in Figure 12b, this software also incorporates fail-over tasks and the data aggregation mechanism illustrated in Algorithm 1. Depending on the physical location of the CH (i.e., if the CH is not an edge CH to the BS), the fail-over mechanism allows this distant CH to multihop its data via a secondary RCH to the BS if the primary RCH is out of service. All CHs, except the edge CHs, incorporate a fail-over mechanism. Figure 13 illustrates an instance of fail-over, where a secondary RCH routes aggregated data to the BS. This software consists of a Bluetooth socket server and client in Python 3.7 scripts that control cluster construction/reconstruction, as outlined in Algorithm 2; fail-over route actions, as described in Algorithm 3; and packet reception from MNs. It also handles data aggregation with fault tolerance techniques inherited from [17], packet  
Figure 11: Proposed multihop CA-IoT development method using the iterative lean approach. transmission to the next-hop RCH or BS, and management of BLE transceiver states. Thus, a distant CH locally stores raw data from its MN and appends its aggregated data to the next-hop primary RCH or secondary RCH in case of fail-over. Unlike a distant CH, an RCH forwards the aggregated data received from its MNs and appends the aggregated data from distant CHs to the next-hop RCH or edge CH. An edge CH receives data via BLE and forwards the locally aggregated data from its MNs; the appended aggregated data from the distant CH/RCH is appended to the BS via LoRa technology. Figure 12b,c illustrate these tasks.