LDAP: Lightweight Dynamic Auto-Reconfigurable Protocol in an IoT-Enabled WSN for Wide-Area Remote Monitoring

Abstract

IoT (Internet of Things)-based remote monitoring and controlling applications are increasing in dimensions and domains day by day. Sensor-based remote monitoring using a Wireless Sensor Network (WSN) becomes challenging for applications when both temporal and spatial data from widely spread sources are acquired in real time. In applications such as environmental, agricultural, and water quality monitoring, the data sources are geographically distributed, and have little or no cellular connectivity. These applications require long-distance wireless or satellite connections for IoT connectivity. Present WSNs are better suited for densely populated applications and require a large number of sensor nodes and base stations for wider coverage but at the cost of added complexity in routing and network organization. As a result, real time data acquisition using an IoT connected WSN is a challenge in terms of coverage, network lifetime, and wireless connectivity. This paper proposes a lightweight, dynamic, and auto-reconfigurable communication protocol (LDAP) for Wide-Area Remote Monitoring (WARM) applications. It has a mobile data sink for wider WSN coverage, and auto-reconfiguration capability to cope with the dynamic network topology required for device mobility. The WSN coverage and lifetime are further improved by using a Long-Range (LoRa) wireless interface. We evaluated the performance of the proposed LDAP in the field in terms of the data delivery rate, Received Signal Strength (RSS), and Signal to Noise Ratio (SNR). All experiments were conducted in a field trial for a water quality monitoring application as a case study. We have used both static and mobile data sinks with static sensor nodes in an IoT-connected environment. The experimental results show a significant reduction (up to 80%) of the number of data sinks while using the proposed LDAP. We also evaluated the energy consumption to determine the lifetime of the WSN using the LDAP algorithm.

1. Introduction

Remote monitoring of various environmental parameters and resources is a major area of interest in the planning of future initiatives and control methods. The Internet of Things (IoT) and wireless technologies make it simple to accommodate a large number of sensing devices and gradually extend their coverage over the monitoring area. The IoT is the extension of the internet from our personal computers and smartphones to various types of devices, ranging from wristwatches to large industrial machines. It facilitates the flow of information from these devices to the end-user through the internet for monitoring and controlling purposes. Wireless communication plays a primary role in connecting most edge devices with the IoT network, and the Wireless Sensor Network (WSN) connects sensors in a network to collect various physical parameters of different systems and accumulate them in central storage.

A traditional WSN connects the sensor nodes (SNs) in a clustered network [1] with static network topologies using multiple base stations (BSs) or a data sink (DS), and transfers the sensor data using multiple repeater nodes [2] to increase the monitoring coverage area. This type of WSN is used mainly for densely populated sensor networks and is not suitable for wide-area remote monitoring (WARM) applications, where both temporal and spatial data is acquired in real time. The clustering procedure in WSNs uses various optimization methods [3] to improve the energy requirement and WSN lifetime. This clustering process may not be suitable for the battery-powered and resource-constraint nodes that are used in remote locations with less accessibility. A WSN also uses multiple special nodes as a hop that retransmits the sensor data to the BS in order to increase the WSN coverage, and also to distribute the energy load over the SNs. In doing so, a WSN implements complex routing algorithms which generate extra processing loads for the repeater nodes and the SNs, and hence, energy consumption is increased.

Many WARM applications, such as environmental, agricultural, and water quality monitoring (WQM), where the resources are geographically spread over a wide area, have little or no cellular data coverage, and face the challenge of connecting with the IoT network. Present WARM applications are implemented using (a) point-to-point or point-to-multi-point connectivity, mainly through satellite links [4], (b) multi-hop wireless communication for long-distance connectivity with the BS, and (c) vehicular mobile SNs [5]. Each of these implementations has limitations in terms of cost, energy consumption, and real-time data acquisition.

Water quality monitoring (WQM) is chosen in this work as a useful case for a WARM application. Water resources are widely distributed over the globe and requires both spatial and temporal monitoring. Eighty percent of our daily consumption comes from surface water [6], of which less than 3% is usable (97.2% of surface water is ocean water and is highly saline). Usable surface water mainly comes from glaciers, rivers, and lakes. A natural solvent, surface water carries contaminating substances while traveling on the ground surface and underground. Through the hydrologic cycle, where surface water travels through the air and comes back again, it also becomes contaminated by air pollution from urbanization [7] and other environmental factors [8,9]. WQM also helps the planning and management of the restoration of water resources and transboundary water distribution [10]. Long-term WQM facilitates the study of ecological changes [11], agricultural conservation practices [12], and long-term changes in water quality parameters. Present WARM is mainly performed by satellite imaging [13], which combines in situ data acquisition with the GIS (Geographic Information System) [14]. On-site digital-color [15], unmanned aerial vehicle (UAV)-based hyperspectral [16], multispectral, thermal, and optical imaging [17] are also used.

To monitor agriculture, the environment, or water resources, using sensors deployed remotely at the site, we need to acquire the data wirelessly using a WSN. The available wireless connectivity systems, such as Zigbee, BLE (Bluetooth Low Energy), and WiFi, have very short range [18] compared to the geographical distributions of the water resources. Long-range wireless connectivity based on cellular networks, such as GPRS (General Packet Radio Service), 3G, WiMax, LTE (Long-Term Evolution), and NB-IoT (Narrow Band-IoT), lacks geographical coverage of most of the water resources due to large power requirements and infrastructural and operational costs. On the other hand, the long-range and low-power wireless technologies, such as LoRa (Long-Range), Sigfox, and Ingenu, are not capable of image-based monitoring. Lastly, the network topology to be used for the WSN depends on the geographical distribution and locations of the resources and the parameter to be monitored.

Therefore, considering the limitations of wireless technologies, the need for various on-site sensors over the widely spread resources, and the lack of accessibility, this research proposes a lightweight dynamic auto-reconfigurable protocol (LDAP) to facilitate the implementation of the sensor network for real-time and long-term WARM applications. Some sensor-based solutions, including the presently available WSNs used for WARM applications, are described in the following section, followed in Section 4 by the problem formulation and the detailed description of the proposed LDAP. Section 5 describes the field trial of the LDAP for a WQM application, followed by Section 6, describing the performance of the LDAP in terms of features and WSN implementation. Section 7 concludes the paper with the future scope of LDAP applications.

2. Related Work

Research work related to WSN implementation for WARM applications are studied for this paper. WSN coverage can be improved by using multiple hops, long-range wireless links, or by introducing mobility to the WSN elements, such as SNs or a DS. Multiple hops in a WSN require network-specific routing protocols. For a WARM application such as WQM, various underwater routing protocols [19] have been proposed that use multiple transmission paths, a layered network, the creation pf a cylindrical path, the fragmentation of the packet to multiple forwarder nodes, multiple mobile data sinks, and mobile repeater nodes. However, because of the underwater noise, multipath delay, low bandwidth, and the limited mobility of the nodes, these routing protocols are not suitable for above surface WARM applications which require wide-area coverage. In another study, the lifetime of the WSN is improved by event-driven data transmission [20]. This type of WSN is ideal for a static WSN with clustering, but lacks coverage. Compressed sensing is proposed in [21] to reduce the total energy consumption of the WSN where most of the sensors are used to measure very similar parameters. This may suffer spatial relations of the data for a WARM application where different types of parameters need to be acquired. In [22] base-station relocation using various local or global optimization algorithms are used to achieve wider coverage and energy balance in a densely populated WSN, which is not capable of continuous relocation to cover large geographical areas required for WARM. An analysis of the relocation or positioning of a mobile DS in a pre-clustered WSN using various optimization algorithms is presented in [23]; however, it is only suitable for static and densely populated clustered WSN.

LoRaWAN (LoRa Wide Area Network) is a MAC (Media Access Control) layer protocol [24] on the LoRa physical (LoRa-PHY) layer used to control channel access and reduce collision and channel congestion. The LoRaWAN protocol stack is described in Section 4.1. A secure device-to-device communication using the LoRaWAN-IP (Internet Protocol) gateway is proposed in [25] to increase security, but it also increases energy consumption by 5%. Therefore, it is not efficient for WARM applications in terms of power consumption and bandwidth requirement, since the data travels inefficiently over the node to the gateway link. The LoRaWAN-based ADR (Adaptive Data Rate) scheme in [26] is implemented with link-check and acknowledgment features. This algorithm is dependent on criteria that may cause an unnecessary delay while establishing the links, and may also cause unseen data loss for a densely populated mesh network. Another option with the LoRa-PHY-based multi-hop routing [27] to the LoRa-IoT gateway also may suffer a time delay for a long TOA (Time On Air). It may not support topology-independent routing that is essential for a WSN in WARM applications. In [28], a WSN with the LoRa interface is implemented using a random-number-based clustering algorithm, which is suitable for static star topology. In [29], allocation of a specific spreading factor for each subnet is used for a LoRa static mesh WSN to improve coverage efficiency. Both these algorithms [28,29], may not be suitable for a mobile DS, because they cause topological changes in the network. A low-power data reduction technique is implemented in [30], using dynamic sub-sampling to reduce LoRa traffic for an environmental monitoring application. Given the above drawbacks of LoRaWAN and multi-hop transmission using LoRa-PHY, only a single-hop LoRa link was considered for WARM applications for the proposed LDAP.

UAVs are also used to provide mobility for remote data acquisition, in which dedicated SNs are mounted on the UAV, or UAV-based networking is implemented. However, UAV-based network communication suffers connection disruption, causing data loss due to its frequent mobility and dynamic routing [31]. To overcome this issue, there are various routing protocols, such as the Ad-Hoc on-demand distance vector (AODV), dynamic source routing (DSR), optimized link state routing (OLSR), and geographic routing protocol (GRP) currently being developed [32]. An energy-efficient UAV-routing protocol for a WSN is proposed in [33], where the energy efficiency of the SNs and the dynamic distance with a traveling DS is considered to determine the shortest routing path. This type of optimization may perform better in a densely populated WSN and may not be suitable for a WARM application where the SNs are widely distributed. An UAV-WSN routing protocol is implemented in [34] based on the shortest total path, using multiple UAVs as agents, which is mainly suitable for a clustered WSN.

Besides the WSN, there is some off-line or point-to-point data acquisition performed for WARM applications. Many mobile sensor nodes are implemented by being mounted on autonomous vehicles such as floating boats [35], amphibious vehicles [36], UAVs [37], and underwater vehicles [38]. All of these require a considerable amount of electric energy for their mobility. These vehicles may not be capable of traveling the long range required for a WARM application. Moreover, static SNs powered by a solar panel [39], wireless power transmission [40], and network-connected sensors using ZigBee [41] need a large number of BSs for wider coverage. Satellite-based wireless data transmission is used in [42] for remote locations, but it is cost-intensive when using a large number of SNs. Community-based learning and data gathering [43] using smartphone apps [44] are being studied for their cultural acceptance, accessibility, and cellular network coverage requirements.

3. Problem Formulation

The limitations of currently used WSN technologies for WARM applications are:

-

A satellite-based solution requires considerable power and is very expensive due to image data acquisition and processing.

-

Satellite-based sensor data acquisition is a high-cost and high-energy solution and therefore, is used only to acquire data from a few locations or those of concern.

-

Present WSN technology using a short-range wireless link, such as ZigBee or Wi-Fi, requires a large number of sensor nodes for extensive coverage.

-

A WSN with a long-range wireless link, such as LoRa and Sigfox, may reduce the sensor node count. However, this requires a large number of base stations, as most of the water resources have no or inadequate cellular coverage. This will eventually increase the cost.

-

A large number of sensor nodes and base stations will require complicated multi-hop data routing. It is not cost effective in terms of energy cost effective or resource requirements, and may induce latency for some wireless technology, such as LoRa.

-

Finally, the lack of or poor unavailability of cellular data coverage, including the NB-IoT for widely distributed water resources, is a bottleneck for IoT connectivity.

Along with the above technical limitations, WARM requires a considerable volume of data acquisition for its distributed resources and a wide range of quality parameters. This requirement is further intensified because of the randomness and fuzziness of acquired data [45], the spatial and temporal variation of the parameters [46], and its dynamics [47]. The WSN for a WARM application, such as WQM, also demands an IoT connectivity to utilize its cloud-based data processing [45] for various reporting and modeling types. Therefore, an IoT-connected WSN is a preferable choice for this type of WARM application.

Figure 1a shows the water resource distribution in lower Northern Saskatchewan in Canada with five different zones based on their distribution and cellular network coverage availability.

Table 1. WSN requirements for the water resources shown in Figure 1a. LDAP: lightweight dynamic auto-reconfigurable protocol.

Zone	Dimension L × W (km × km)	Number of BSs Required			Number of SNs Required			Number of Hops Required			Energy Efficiency * (%)
		Short- Range [1]	Long- Range [30]	LDAP	Short- Range [1]	Long- Range [30]	LDAP	Short- Range [1]	Long- Range [30]	LDAP	Short- Range [1]	Long- Range [30]	LDAP
1	30 × 80	60	16	3	3000+	480	480	8	5	1	94.2	95.0	99.7
2	30 × 55	30	8	2	1000+	150	150	5	4	1	96.5	94.7	99.3
3	50 × 25	40	12	3	2000+	300	300	8	5	1	94.2	94.0	99.5
4	15 × 55	15	4	1	150+	50	50	8	5	1	71.2	88.5	99.0
5	10 × 25	6	2	1	100+	25	25	5	3	1	92.9	95.4	98.0

* Explained later in Section 6.3.

summarizes the area covered by each zone with its IoT-WSN size measured by visual estimation and also shows the required number of SNs, the BS, and the highest number of hops using the presently available technology. The dimensions of the zones mentioned here is the measure of length and width. This WSN deployment is done using the short-range link ZigBee, commonly used for various clustered WSNs [1], and the long-range link LoRa, used for wide-area coverage [30]. The short-range link is of 500 m and the long-range link 1 km to 5 km. Figure 1b shows a probable WSN deployment in zone 1 to monitor almost 80% of the water resources. The rest of the zones can be distributed similarly. There are 16 WSNs in zone 1; each one has at least one BS, and the number of SNs under every BS depends on the range of the wireless link used and the preferable number of hops. IoT connectivity can be implemented using the available cellular data network coverage close to the urban area and long-range point-to-point wireless links for the remote area.

From Table 1, it can be seen that the WSN dimension is not directly related to the geographical area but to the distribution of the water resources, the technology used, the availability of wireless connectivity, and the network topology to be used. A large number of SNs increases the network topological complexity, which can be reduced using long-range SNs and a larger number of BSs. However, it still suffers from the network routing complexity, the increased energy requirement for the repeater nodes introducing heterogeneity, and the requirement for various optimization algorithms [48] or a layered protocol [49]. Considering the above limitations and complexity of the available WSN technologies, this paper proposes a lightweight, dynamic, and auto-reconfigurable WSN protocol (LDAP) for the resource and energy-constrained SNs. This LDAP uses a homogeneous network with both static and mobile data sinks instead of static or relocatable base stations [23]. The improvements due to the proposed LDAP are also evident in Table 1, in terms of the number of BSs, number of hops, and energy efficiency of the WARM network, which will be described in the performance analysis section. Implementation of the proposed LDAP using an UAV where ground mobility is limited and the WQM application are described in Section 4.5.

4. Proposed Solution

Figure 2 shows the geographically distributed water resources with partial or no cellular coverage for connecting the SNs with the IoT network. Here, the WSN is based on LoRa, and the IoT connectivity is achieved using a LoRa-IoT gateway. It also shows different types of WSN topologies, where a sensor node is acting as a repeater and communicating with a mobile data sink under partial cellular coverage. The mobile DS is mounted on an UAV to access the remote SNs when other means of vehicular movement may not be possible. A mobile DS, under partial cellular coverage, can also act as a LoRa-IoT gateway. On the other hand, an offline mobile DS (position A) stores the sensor data from the water resources with no cellular coverage and uploads the data to the IoT server when it comes to cellular coverage (position B). While designing the proposed dynamic protocol and the SN’s auto self-reconfigurable capability for WARM, our primary focus is on the following:

• Selection of wireless communication technology; and
• Lightweight dynamic communication protocol.

4.1. Selection of Wireless Communication Technology

The requirements of the wireless network are: low power and long-range wireless technology for the WARM-specific WSN, and other wireless technology with higher bandwidth and with a low-power requirement for IoT connectivity. Cellular networks are constantly in transition, deploying newer generation technology such as 3G to LTE, or LTE to 5G. As the entire service provider still to deploy 5G with NB-IoT capability, 3G or LTE is a better option than any other technologies to connect the WSN with the IoT network wirelessly, depending on the bandwidth requirement and availability. However, all cellular networks need an infrastructure with considerably more power compared with SNs. Depending on the WSN dimensions and network topology, it may generate very little to moderate traffic for cellular data networks such as LTE and 3G. Moreover, to provide and maintain cellular coverage for all the water resources, which are mainly in rural areas for WARM, is not feasible either commercially or technologically due to a lack of accessibility. Therefore, we need a non-cellular wireless network for the WSN in some areas and the existing cellular network depending on its availability.

Table 2. Low-Power Wireless Area Network technologies basic features. LoRa: Long-range.

Technology	Standard	Data Rate (bit/s)	Range (km)	Required Power
NB-IoT	3GPP Cellular	250 k	Urban 8, Rural > 25	Low
LoRa	Proprietary	<50 k	Urban 5, Rural > 15	Very Low
Sigfox	Proprietary	100	Urban 10, Rural 50	Very Low
Ingenu	Proprietary	20	Urban 3, Rural 15	Very Low
Dash7	ISO/IEC 18000–7	13 k, 55 k, 200 k	1–2	Very Low
6LoWPAN	IEEE 802.15.4	Less than 250 k	<0.1	Low
ZigBee	IEEE 802.15.4	20 k, 40 k, 250 k	<1	Low
Wi-Fi	IEEE 802.15.11	Up to 54 M	0.2	High
New Wi-Fi	IEEE 802.15.11ah	>150 k, <7.8 M	1	Low

summarizes the basic features of Low-Power Wireless Area Network (LPWAN) technologies [50,51,52], such as LoRa, Sigfox, Dash7, Ingenu, ZigBee, 6LoWPAN, Bluetooth, and Wi-Fi. Although NB-IoT is a cellular technology, it is included in Table 2 as it is designed for IoT connectivity for SNs. Among these LPWAN technologies, LoRa was chosen for its low-power, long-range connectivity, and performance evaluation in several recent works [51]. Table 2 shows that LoRa falls in the third position in terms of range and the second position in terms of data-rate. However, because of the requirement of the cellular infrastructure and the related high operational cost of NB-IoT, LoRa can be chosen for the WSN connectivity for WARM as a low-cost option. Unlike LoRaWAN, LoRa-PHY can be used to achieve more flexibility to configure the WSN topology as star, tree, or mesh by implementing a custom network layer on it. Moreover, LoRaWAN supports three types (A, B, and C) [53] of channel acquisition. In contrast, custom channel acquisition can be achieved using the proposed layer on top of LoRa-PHY; Figure 3a shows the protocol stack used with LoRa-PHY in this paper relating with the OSI layers. Figure 3b shows the LoRa-WAN stack compared with the proposed stack. The basic three layers are shown in this stack, which are the LoRa-PHY, proposed, and application layers. The proposed layer corresponds to the network, transport, and session layers of the OSI (Open Systems Interconnection) reference model. In the network layer, it uses the physical IDs of the SNs and the DS to select the logical route. In the session and transport layers, it forms the LoRa payload packet for the sensor data along with some headers to maintain the connectivity for the logical route. To keep the protocol lightweight for the SNs all these OSI layers are implemented together as a single function, as described in the following subsection.

4.2. Lightweight Dynamic Communication Protocol

Along with the LoRa interface, the WSN coverage can be further enhanced by introducing a mobile DS. However, mobility in the WSN makes the topology dynamic; hence, the communication protocol becomes complicated, demanding more processing resources and energy. Therefore, a lightweight and dynamic protocol is crucial to cope with the dynamic topology while maintaining a long WSN lifetime. This protocol involves both the SNs and DS to keep the WSN homogenous (in terms of energy consumption of the SNs) and to make it dynamic for the mobile DS. The SN needs to have the capability to reconfigure itself for the different network topologies, such as star and tree topology. In the star topology, all the SNs will communicate directly with the DS. In the tree or mesh type, most SNs communicate with another SN called the repeater node (RN) which maintains the DS’s connectivity. A lightweight algorithm for the SN is also developed to reconfigure it as an edge SN or RN dynamically, depending on the direct or single-hop routing requirement for the proposed LDAP. As the proposed LDAP is based on the LoRa-PHY layer, unlike LoRaWAN, a DS-controlled channel access scheme is implemented along with pre-configured addressing for the SNs. The main assumptions are:

-

Each SN and DS has its unique fixed ID;

-

All the SNs are homogeneous in terms of resource and residual energy;

-

The SN is static, and the DS is static or mobile;

-

All SNs and the DS transmit their signals at a fixed transmit power; and

-

The mobile DS travel path is well planned prior to data acquisition.

This proposed protocol is a master-initiated communication protocol to keep better synchronization in the WSN. Figure 4 shows the message format without the LoRa packet header. A single packet can be 12 to 256 bytes. Packet transmitter and receiver types (ST, RT) can be any of the DS, RN, or SN.

Table 3. IoT-WARM Communication packet description of LDAP.

Tag	Full Name	Values	Example
RT	Receiver Type	1/2/3	1: sink, 2: RN, 3: node
RID	Receiver ID	0001 to FFFF	Device ID (1 to 65535)
ST	Sender Type	1/2/3	1: sink, 2: RN, 3: node
SID	Sender ID	0001 to FFFF	Device ID (1 to 65535)
MID	Message ID	1–4	1: Req., 2: Ack., 3: Data, 4: Conf., 5: Init.
SQN	Msg. seq. number	1	0–255 (binary)
PLT	Payload Type	0/1	0: last block, 1: multi-block
PLL	Payload Length	1–245	8 bit data stream
PL	Payload	Binary/ASCII	Sensor data with date-time
EOM	End of message	0/1	0: Last packet, 1: Continuous packet

describes all the fields of the WARM-packet with example values. ST and RT facilitate the SN and DS to configure the WSN dynamically as a star or tree topology according to the WARM requirement. SQN keeps track of the link between the data request to data received in order to cope with the multi-node transmission, mainly in a tree network. PLT and EOM facilitate a multi-packet data transfer for a payload larger than 245 bytes. A multi-packet data transfer can be implemented for offline data acquisition by the mobile DS or for sensor data acquisition at a very high rate, such as multiple samples for every transfer interval. The payload consists of the sensor data, measured parameter unit, and timestamp. It also includes the node ID to implement the message transfer by the repeater node.

The LDAP has three phases: initialization, configuration, and routing. In the initialization phase, the SN configures itself automatically with the sensors connected. The parameters need to be acquired, including the interval for data acquisition and the node’s initial energy state. This configuration can also be done at the beginning of the WSN deployment or at any time required by using the configuration message (MID = 5). For the mobility of at DS, both configuration and routing phases are performed simultaneously in the data transfer request message (MID = 1). The WARM configuration message (MID = 4) is also implemented for a fixed topology while using a static DS. The acknowledgment message (MID = 2) is implemented for the synchronization of the data transmission message (MID = 3) to enable sensor data transmission from the edge SN to the DS or RN, and from the RN to the DS. Figure 5a shows the direct DS to SN data transfer protocol. Figure 5b shows the configuration and data transmission from the DS to SN through the RN, and Figure 5c shows the data transfer protocol between the SN and RN. Every data transfer from the SN to DS through the RN ensures a single-hop data transmission to reduce data transfer energy consumption. The selection of a different SN as the RN for every round of non-direct data transfer helps to maintain the energy balance in the WSN, thus keeping the WSN homogeneous, which is very important for dynamic network topology. This dynamic RN selection can be performed by proper DS travel route planning, using an offline optimization algorithm.

An algorithm to perform LoRa wireless link configuration, packet construction, data processing, and synchronization functionality for the LDAP is implemented both in the SN and the DS. Figure 6 shows the software algorithms implemented in the SN and DS. In Figure 6a, the SN performs the initialization and configuration at the start, then reads the sensor and waits for a message from the DS for data upload to the DS. After the initialization phase, the DS starts communication with the SN in a loop and tries to acquire sensor data from the SN database, as shown in Figure 6c. If no SN responds in a specific time, it requests a SN with the lowest RSSI (Received Signal Strength Indicator) and highest energy level to relay the missing SN’s data. Figure 6b shows the dynamic RN implementation algorithm for the SN. Dimensioning of the WSN and planning the DS travel path depends on the WARM implementation, network configuration, and LoRa link quality described in Section 6.

4.3. Timing Model

The number of SNs covered by a mobile DS depends significantly both on the data acquisition interval and the LoRa Time On Air (TOA). Because LoRa uses Chirp Spread Spectrum (CSS) modulation, its TOA is highly dependent on the bandwidth (BW), and the spreading factor (SF) used, as shown in Equation (1). This equation is derived from the equation given in the manufacturer data sheet [54] and usies a set of nominal values for the parameters given in

Table 4. LoRa parameters with their default and calculated values.

Symbol	Description	Value
SF	Spreading Factor	7
BW	Bandwidth (kHz)	250
CR	Code Rate	1
nPR	Preamble length	8
H	Explicit Header Enable (0: enable)	1
CRC	Cyclic Redundancy Check Enable (1: enable)	0
D	Low data-rate enable (0: disable)	0
UCH	LoRa channel utilization	10%
TOAmax	Time On Air (TOA) at maximum payload size of 245 bytes	197.25 ms
TOAmin	TOA at minimum payload size of 16 bytes	33.41 ms

. It was validated using the online tool [55]. Therefore, network coverage by a mobile DS also depends on the BW and packet length used. The total time for data acquisition depends on the routing from the SN to the DS, as shown in Figure 5. For direct SN to DS data transmission, the total time T_AQSN can be calculated using Equation (2). The total time of data transmission from the SN through the RN, T_AQRN, will be the sum of several data requests, acknowledgement, and data transmission messages, as shown in Equation (3).

$$\mathrm{TOA}=\left(20.25+\mathrm{ceil}\left[\left(\frac{2\mathrm{PL}-\mathrm{SF}+7}{\mathrm{SF}}\right)\right]\times 5\right)\left(\frac{2^{\mathrm{SF}}}{\mathrm{BW}}\right)$$

(1)

T_AQSN = T_RDS + T_DSN

(2)

T_AQRN = T_RDS + T_ARN + T_RRN + T_DSN + T_DRN + T_ADS

(3)

where T_RDS is the TOA of the data request message from the DS, T_ARN is the TOA of the acknowledgment message; T_RRN is the TOA of the data request message from the RN; T_DSN is the TOA of the data message from the SN; T_DRN is the TOA of the data message from the RN; and T_ADS is TOA of the acknowledgment message from the DS. For simplicity, all the requests and acknowledgement messages are considered to generate a 16-byte LoRa payload, and the data transmission and retransmission messages are 256 bytes. Therefore, T_RDS = T_ARN = T_RRN = T_ADS = TOA_min, and T_DSN = T_DRN = TOA_max. Then Equation (3) can be written as Equation (4), and the time can be calculated using the values given in Table 4.

T_AQRN = 4TOA_min + 2TOA_max= 4 × 197.25 + 2 × 33.41 = 855.82 ms

(4)

The last acknowledgment message from the DS is an optional message for event-sensitive data transmission (hence, T_ADS = 0 and T_AQ = 822.41 ms). The maximum number of SNs covered by a single DS can be calculated using Equation (5). U_CH and R_OH stand for wireless channel utilization over the whole WSN and the SN’s processing overhead ratio, respectively. Given a data acquisition interval of 15 min and 20% processing overhead (which depends on the SN hardware design and is obtained from the experimental data for the implemented SN), the maximum number of SNs (N_max) under one DS is found to be 142 for the given LoRa parameters.

$${\mathrm{N}}_{\max }=\mathrm{ceil}\left(\frac{\mathrm{Duty}\mathrm{Cycle}}{\mathrm{T}}\times {\mathrm{U}}_{\mathrm{CH}}\times {\mathrm{R}}_{\mathrm{OH}}\right)$$

(5)

4.4. Energy Model

The total energy consumption for a message or data transmission by the SN is the sum of event-specific energy consumption and calculated using Equation (6). The power and timing measurements were performed during the lab experiments, as described in Section 6.3, where P_AC, P_RX, and P_TX are the power requirements at active, LoRa-receive, and LoRa-transmit events, respectively, and T_AC, T_RX, and T_TX are the times required for those activities. This total energy requirement is highly dependent on the hardware design of the SN. For complete data transmission using the LDAP, the total energy consumption of a SN can be given by Equation (7), where E_A1 is the energy consumption for request and acknowledgment messages (T_TX = TOA_min) and E_A2 is the maximum energy consumption for a data transfer message (T_TX = TOA_max). Similarly, the total energy consumption of the RN, for data transmission through it, can be provided by Equation (8). Therefore, the total WSN energy consumption can be calculated using Equation (9). The average per node energy requirement (E_AV) per cycle can be given by Equation (10), where k is the number of data transmissions through the RN. Energy efficiency (η) for the proposed LDAP can be calculated using Equation (11). From this equation, it is shown that the energy performance of the proposed LDAP depends on the number of hop or repeater nodes used in the WSN. Energy consumption calculation values are given in

Table 5. Event-wise energy calculation of the SN with a 3-sec cycle using the LDAP.

Event	Duration (mS)	Voltage (V)	Current (mA)	Power (mW)	Energy (mJ)
Active	TAC = 2407	5.01	31	PAC = 155.31	EAC = 373.83
LoRa Rx	TRX = 336	5.01	44	PRX = 220.44	ERX = 74.07
LoRa Tx	TTX = 135	5.00	148	PTX = 740.00	ETX = 99.90
Full cycle	2878				547.80

, using the experimental values of T_TX.

E_A = P_ACT_AC + P_RXT_RX + P_TXT_TX

(6)

E_SN = E_A1 + E_A2

(7)

E_RN = 4E_A1 + 2E_A2

(8)

E_WSN = N_maxE_SN + kE_RN

(9)

E_AV = E_SN + (k/N_max)E_RN

(10)

η = 1 − k/N_max

(11)

4.5. Mobility Model

The proposed LDAP can be implemented using any type of ground or over-the-ground vehicle depending on the WARM applications. However, most of the WARM applications may require remote connectivity where the SNs are difficult to access using ground vehicles. Therefore, for the WARM case, an UAV-mounted DS is considered. Figure 7 shows an UAV-mounted DS, which is moving from its initial position, a, to b and then to c, at a ground speed of V_UAV, at an altitude of H, and with the LoRa link distance from the RN represented by L. The projected position of the DS is shown as DS’ at different times (at a’, b’, and c’). The projected distance between the RN and the DS’ is D, which is considered equal to H for optimized altitude vs. the wireless link coverage condition, so that D = H = 0.7 L. An UAV-mounted DS needs to perform two tasks; link establishment and data transfer. To keep the proposed LDAP lightweight, these two tasks are designed to meet the UAV speed and also the LoRa TOA. According to the experimental setup used for the WQM case, we calculated a data transfer time through the repeater node (T_AQRN) as 856 ms for the maximum sensor data size of 245 bytes. We can calculate the number of SNs data messages to be transferred using a low to medium height UAV, such as the Zephyr 7 [56], with the following conditions:

-

UAV altitude is 3.5 km for a 5 km LoRa link;

-

UAV maximum ground speed = 50 km/hr = 13.8 m/s = 833 m/min; and

-

The data transfer ratio through the repeater node = 100%.

With the above conditions where the minimum distance between the DS and SN (L) is very high compared with the distance traveled per second (or the time of T_AQRN) by the UAV, the DS can be considered static for the period of T_AQRN. As shown in Figure 7, when all the SNs are distributed at a minimum distance of 3.5 km (0.7 L) from the RN, they will communicate with the DS through the RN only in the worst case scenario. The DS can travel half of the SN-DS distance (3.5 km) in 126 seconds without losing the connection with the RN, and during this time it can receive data from at least 147 SNs. Table 1 shows that with the LDAP, the SNs are much more distributed or the number of SNs within the 3.5 km range is lower than the number of SNs that the UAV-mounted DS can acquire data through the RN. The maximum number of SN density can be calculated as 56 (3.5* 480/30) for zone 1. Therefore, the UAV-mounted mobile DS with the LDAP can easily be implemented for the WQM case as described in Section 3. Similarly, using the proposed LDAP, the mobile DS mounted on a specific UAV, traveling at an altitude of H (=0.7 L), can acquire data from the number of SNs (SN_UAV) which can be calculated using Equation (12).

$${\mathrm{SN}}_{\mathrm{UAV}}=\left(\frac{0.7\mathrm{L}}{{\mathrm{V}}_{\mathrm{UAV}}}\right)/\left(2{\mathrm{T}}_{\mathrm{AQRN}}\right)$$

(12)

4.6. WSN Dimensioning

Dimensioning of a WSN mainly depends on various application-specific requirements and can be done using automated network dimensioning tools. Dimensioning of a widely distributed WSN depends on several factors, such as the number of SNs, maximum and minimum link distances. The data acquisition interval, the number of BSs/DSs, and, mostly, the distribution of the data sources from which the parameters’ variability can be acquired. Given all these factors, using the timing model of the LDAP described in Section 4.3 and based on visual inspection, a WSN can be dimensioned for a given area as shown in Figure 1a. Table 1 shows the dimension of a WSN using the LDAP, while keeping the number of SNs unchanged for better differentiation between them in terms of the number of BSs/DSs. For zone 4 and zone 5, the number of SNs is very low to get the benefit of a mobile DS; hence, the WSN with a mobile DS is more efficient with widely distributed SNs than with the densely populated SNs.

5. Field trial and Validation

The field trial consists of the hardware implementation of the SNs, the WSN implementation in the field near the water resources, and lab experiments for SN performance measurement.

5.1. Hardware Implementation

A low-power SN is designed to implement and test the proposed LDAP using an 8-bit microcontroller (MCU), namely the ATMega328, with only 32 kB of ROM (Read Only Memory), 4 kB of RAM (Random Access Memory), and running at 16 MHz. Figure 8a shows the hardware block diagram of the SN with LoRa and sensor connections. With the SX1276 LoRa module at 915 MHz, the MCU is capable of interfacing four analog sensors and four digital sensors simultaneously through the built-in ADC (Analog to Digital Converter) and I2C (Inter Integrated Circuit) interface, respectively. The MCU used in the SN is powered by a 12 V to 5 V voltage converters, and the sensors connected with it also need to operate at 5 V. The total SN is powered by three 18,650 Li-Ion batteries, each of 6000 mAH, providing 10.8 V to 12 V, which can also be replaced by a 12 V lead-acid battery with a 12 V solar panel for external charging for lengthy remote operations. Figure 8b,c show two SNs connected with a LoRa wireless module, battery, and the different types of sensors used in the field trial. The DS and LoRa-IoT gateway are implemented using a Raspberry-Pi with LoRa, Wi-Fi, and a dedicated LTE-Wi-Fi access point.

5.2. Experimental Setup

As WQM is used here to show the performance of the proposed LDAP algorithm, we used different types of sensors with the SNs mainly to collect various water quality parameters such as pH, turbidity, and temperature, and air parameters such as temperature, pressure, and humidity. In Figure 9a, a Google map view of one field trial is shown, where three SNs (red dots) were installed with one static DS (red triangle) and one mobile DS; lines of different color show the LoRa links. In the first phase, we collected sensor data using the static DS1 from SN1, SN2, and SN3 directly, and then we collected data from SN1 via the SN3 as the RN using DS2 (red lines). SN1 has no line of sight (LOS) with DS2 (the green line shows the link with no line of sight). In the second phase, we collected data from SN1 using a mobile DS. Figure 9b shows the map view of some positions of the mobile DS. We also measured the energy performance of the SNs using an energy monitoring and logging setup in the laboratory.

6. Performance Analysis

We evaluated the performance of the proposed protocol by measuring the SN’s functionality as a RN in terms of the data delivery rate through the RN, the LoRa performance with the mobile DS, and the energy performance of the SN in different functional modes.

6.1. Functional Performance

We evaluated the functional performance of the SNs in a fully configured IoT network. We used seven SNs to collect data from different types of sensors and send them to the IoT server through two data sinks. The system was also configured to form the network in two different ways: star networks (SN to DS direct link) and tree networks with the DS using any one SN as the RN, where one SN does not have direct wireless connectivity with the DS. Data from a SN were acquired at three-second intervals, which is a very high rate compared to 15-min intervals; thus, more than 800 packets were collected during the two-day experiment. Figure 10a shows the pH and turbidity data taken from the South Saskatchewan River gathered directly from two different SNs to the DS and via the RN, respectively. Figure 10b shows the air-quality data received from the temperature, pressure, uncalibrated TVOC (total volatile organic compound measure), and humidity sensor on the river bank. Data delivery success rate between the SN and DS was 100%, and through the RN was 99%.

6.2. Network Performance

Network performance was measured in terms of RSSI (Received Signal Strength Indicator), SNR (Signal to Noise Ratio), and data loss from the SN received by the DS. For the WARM application in some remote locations using a mobile DS radio signal, the quality depends on various environmental parameters along with the distance between the SN and the DS. With varying distances, data loss is the primary performance indicator, and when measured was found to depend on both the RSSI and SNR. Figure 11a shows that data loss becomes significant when the RSSI goes below −95 dBm with the SNR below 0. Increasing data loss was observed with a decrease of the SNR and RSSI, mainly above a 1000 m distance and without a line of sight. Figure 11b, c show the relationship between the RSSI and SNR with the distance between the SN and DS, respectively; the line curve is for the median values, and the box graphs show the ranges of RSSI and SNR values at different distances. These results can also be used by the mobile DS to improve the data delivery rate by using a RN or by changing the transmit power or the travel path.

6.3. Energy Performance

The SN’s energy performance is one of the first parameters to measure the SN’s life in the field and the lifetime of the WSN. The SN has three main components for measuring energy consumption: the MCU, the LoRa module, and the sensors. Irrespective of the components used, the total power consumption of the SN varies at the different events performed by the SN. These events mainly depend on the software algorithm and transmission time required for the protocol used. The events used to measure the SN’s energy performance are startup-mode (the MCU is initializing), active mode (the MCU is running the normal functions such as housekeeping and sensor reading), sleep mode (the MCU is not running, and only the RTC (Real Time Clock) and sensor are functional), LoRa data receive mode, and LoRa transmission mode. We use a DC energy measuring unit and log the data to monitor the input voltage, current, and power consumption of the SN, at a resolution of 1 mV and 1 mA. The voltage is measured at the input of the sensor node as shown in Figure 8a and after the DC-DC converter. The DC-DC converter efficiency is considered to be 85% to calculate the lifetime of a node with the power supply used. The SN is configured to transmit data at three-second intervals to measure the energy consumption of the SN at different events, and the MCU operates at 16 MHz without any sleep mode. In the beginning, the MCU is re-started to begin the initialization event; it then moves to the active mode followed by the LoRa reception and transmission activities. The entire event’s duration and power requirement are measured using an energy meter and data logger. Table 5 summarizes the event duration, voltage, current, power, and energy consumption, including energy consumption for a complete cycle. In this experiment, LoRa transmission time is kept close to the TOA_max by using a data packet size of 165 bytes. For the field operation with a data transfer interval of 15 min, the MCU can be in sleep mode most of the time other than when it is active, and during LoRa transmission events. In this configuration, the LoRa transmission channel utilization was calculated as only 0.015%, which is very low compared with the LoRaWAN channel utilization ratios of 0.1% and 1.0%. Therefore, using LoRaPHY can increase the LoRa channel capacity, and hence, can accommodate more SNs in a specific WSN. SN lifetime using three 18,650 Li-Ion battery of 3.6 V and 6000 mAH, can be calculated as 681 days, which is a rough estimate and may depend on the working temperature of the sensor node itself.

The overall energy efficiency of the WSN using the proposed LDAP can easily be calculated using Equation (11). One method to measure the energy efficiency of a specific WSN algorithm or protocol is to express it in terms of the ratio of the energy required without implementing that algorithm or protocol and the total WSN energy required with the algorithm or protocol implemented. As the energy required for the algorithm or protocol is highly dependent on the method of implementation (software algorithm or methodology), the energy efficiency of the LDAP is not comparable with other routing protocols or algorithms using their proposed implementation. However, a comparison in terms of the energy efficiency is shown in Table 1 based on the general concept and Equation (11), where k is calculated using the number of hops (h) and the data relay factor ($\mathsf{\mu }$), as shown in Equation (13).

$$\mathrm{k}=\mathsf{\mu }\left\{\frac{h}{2}\left(h+1\right)\right\}$$

(13)

Therefore, k is highly dependent on $\mathsf{\mu }$, which is highly dependent on the WSN topology used, and $\mathsf{\mu }$ is variable over the whole WSN. It is lower for the higher hops than the lower ones. For a WSN with a short-range wireless link and a higher number of hops, $\mathsf{\mu }$ will be very low. If the same values of $\mathsf{\mu }$ are used for both the WSN with short-range [1] and long-range [30] wireless links it will have very low (50% to 70%) energy efficiency, which is not practical. To improve the energy efficiency of traditional WSNs, various clustering and optimization algorithms are implemented with the added costs of SN hardware resources and processing energy. Therefore, the energy efficiency shown in Table 1 is calculated using different values for $\mathsf{\mu }$; $\mathsf{\mu }=0.1$ for a WSN with a long-range wireless link. For a WSN with a short-range wireless link with hops fewer than 5, $\mathsf{\mu }$ = 0.1, and with hops greater than 5, $\mathsf{\mu }=0.05$. As the proposed LDAP is designed considering only one hop, $\mathsf{\mu }=0.5$ is used for the WQM case. Even after optimization cis applied to the traditional WSNs, the proposed LDAP shows an improvement in terms of energy efficiency.

6.4. Timing Performance

Timing performance of a routing protocol can be measured in terms of the time required for the data to be received by the DS from the SN after sending the data request message. The data request message has two main components: processing time (including message decoding, data encryption, and data packet processing) required for the specific protocol and the TOA of the wireless technology used. For the LoRa wireless network used with the proposed LDAP, the processing time (around 7 mS as measured for the prototype SN) is around 5% compared with the LoRa TOA (135 mS).

6.5. Features and Comparison

The proposed LDAP achieved the objectives of the WSN coverage in terms of the number of SNs and its geographical coverage, as well as meeting the long lifetime requirement. Table 1 shows a significant reduction (50%) in data sinks in zone 5 with cellular coverage, and is significantly reduced (81%) in zone 1 with poor cellular coverage. Moreover, other main features of the proposed LDAP are as follows:

• Unlike the UAV-mounted SNs or multi-hop static WSN, a mobile DS can increase the monitoring area coverage significantly. The proposed LDAP can acquire the sensor data using the mobile DS mounted on an UAV for most of the WARM applications where ground mobility may not be possible. UAV-based mobility is not possible for the SNs with short-range wireless links [1], as described in Section 3, due to the required altitude of the UAV; hence, long-range wireless connectivity is required. Moreover, multi-hop routing used for the traditional WSN may not be suitable for the mobile DS due to the routing complexity of the dynamic network topology.
• A mobile data sink is more energy efficient than a mobile sensor node, as the number of DSs is much lower than that of the SNs that would be required to cover the same area being monitored. The energy required to facilitate mobility to the SN or DS depends highly on the type of vehicle (or other means) used is not considered. However, for the same type of mobility, a WSN using a mobile DS requires significantly lower energy compared with the WSN with a mobile SN. For a static SN with a static BS, there is no energy required for mobility; however, it may incur other costs due to the high number of BSs. Unlike image-based data acquisition, WARM applications do not require continuous streaming and the SNs can store data over time. The stored data can be transmitted when a wireless link is established with the DS, and in this way, the SN can acquire sensor data at a rate as high as 1-min intervals and transmit it at 60-min intervals using the proposed LDAP.
• In terms of coverage, the number of mobile SNs is reduced compared to the static SNs; however, it may lose data coherence over time, which can be overcome by using static SNs associated with a mobile DS.
• Most of the routing optimization, clustering, and cluster head election in the WSN is performed using the residual energy and location of the SNs to keep the energy consumption of the SNs uniform (using a smaller cluster size closer to the DS) over the WSN. However, most of these procedures do not consider the environmental impact on the wireless signal quality, and require high processing resources and energy for the SNs, or use heterogeneous nodes (special nodes with higher energy consumption and capacity). The proposed LDAP can select direct RN-based data transmission, based on the residual energy, RSSI, and SNR of the SNs. Therefore, it is more immune to the environmental impact on the wireless signal quality and can maintain the energy balance among the SNs with very low energy consumption due to its light weight.
• Moreover, most of the present cluster-based WSNs use multiple hops for data transfer, which require maintaining a static network topology or a complex routing optimization for any changes of topology due to the relocation of the BS. In contrast, the proposed LDAP does not depend on the network topology, as it uses direct or single-hop data transmission from the SNs to the mobile DS.
• Present WSNs require complex clustering and routing algorithms to improve the efficiency of overall energy consumption. The complexity and processing load of this type of algorithm demand an additional resource (such as a high-speed processor and extra memory), which introduces energy overhead and cost. It makes the deployment of the WSN complicated and reduces scalability. On the other hand, the proposed LDAP uses only direct and single-hop data transfer, which is lightweight and suitable for resource-constrained sensor nodes. In addition, it reduces the deployment and expansion overhead in WSN implementations.

Some features of the proposed LDAP and other available technologies are summarized in

Table 6. Features of the proposed protocol and comparison with other technologies.

	Proposed LDAP	Remote Node [42]	Vehicle-Mounted [35,36,37,38]	Conventional WSN [39,40,41]
SN type	Static	Static	Mobile	Static
Network topology	Dynamic	Static star	Static Star	Static Star/tree
DS type	Static/mobile	Static	Static	Static/relocatable BS
Routing hop	Direct, single hop	Direct	Direct	Single/multi-hop
Energy consumption	Low	Low	High	Medium
Wireless interface	LoRa	Satellite	-	ZigBee and other
Coverage	Wider coverage using UAV mounted DS	Small coverage for static SN	Limited coverage using only mobile SNs	Wider coverage using a large number of nodes
Processing overhead	Very low	NA	NA	Moderate to High
Deployment complexity	Low	Moderate	Moderate	Moderate to High
Features	Low cost, low power	Low cost, less coverage	High cost,	Need network planning or optimization

. Unlike vehicle-mounted mobile SNs, the LDAP uses static SNs to reduce energy consumption and the complexity of WSN deployment. It also helps to implement mobile DSs over the wide WSN, which is not used in any type of existing solutions. The use of mobile DSs requires support for network topology changes, which is achieved easily by avoiding multi-hop data transmission as done in most of the conventional WSNs. Unlike the satellite link and other wireless technologies such as Zigbee, the LDAP is optimized for LoRa (higher TOA than non-CSS technologies), which makes it consumes less energy and capable of wider geographical coverage.

7. Conclusions and Future Scope

This paper has addressed the main challenge of an IoT-based WARM system, where real-time data acquisition is required for the distributed resources. We have proposed a lightweight dynamic auto-reconfigurable protocol (LDAP) for the SNs using a mobile DS to increase the WSN coverage geographically and to maintain a long WSN lifetime. The proposed LDAP also focused on minimizing the number of hops for data transmission, which also reduced the routing complexity, and the DS-based control further reduced the processing load of the SN, thus increasing its lifetime. It is shown that the efficiency of the proposed protocol is highly dependent on the geographical distribution of the SN, and maximum benefit can be achieved for two-dimensional (over both the length and width of the monitoring area) SN distribution. Maximum coverage and energy balance of the WSN also depend on proper path planning for the DS, which can be achieved offline by implementing various path optimization schemes. For future study, an offline or real-time path planning algorithm for the mobile DS could be developed to achieve the energy balance of the proposed LDAP. The coverage of the WSN for some applications, such as smart farming, where the sensor nodes are distributed both longitudinally and laterally with the direction of the moving DS, could be improved. A minimal clustering algorithm with a single-hop transmission could be implemented for a mobile DS.