RF Communication and IoT Paradigms System Proposal for Effective Consumption and Equity Distribution of Community Water in Developing Countries: A Case Study

. Abstract — Water scarcity poses a serious threat to the population in the most areas of developing countries. In addition to that, the traditional manual nearby approach of following up the water distribution network is unable to ensure an effective and equity use of the small water resources available. A dedicated real-time monitoring system based on radio frequency (RF) communication and internet of things (IoT) paradigms is proposed in this paper. This monitoring system is essential and constitutes a proposed solution for the local water management and equity distribution of the available poor water resources. An alert system recalls users to any abnormal water usage to reduce water loss or to check and solve usual leakages. A customer’s water consumption visualization as well as a setting of his desired consumption alert system are performed using a home dashboard; the monitoring of the system by the water utility company is achieved using a web-based system through Thingspeak cloud computing platform. For an immediate and easy local implementation of the prototype, the system technology was chosen in already validated most cases; in other words, Commercial-Off-The-Shelf (COTS) components were used. For better and optimum results, most dedicated similar COTS components will be selected using the already running systems.


Introduction
Despite the constant increasing of the population and the extension of the water distribution systems in most of the developing countries, the main distribution infrastructure (e.g. water tower, diameter of pipes, etc.) have not changed over the years. In addition to that inadequacy between the population and infrastructures, important quantities of water are wasted due to frequent failures. Moreover, the organization of the United Nations has reported that 1.2 billion people live in areas of water scarcity, and the number will increase to 1.5 billion by 2025. As presented in Figure1, more than 2.8 billion people from 48 countries will face water scarcity problems by 2025 [1]. So, the ratio between the drinking water production and the population density in those countries is very poor; equity water distribution and a real time monitoring of water leakages could be a contribution to solution. In Cameroon which is one of those concerned developing countries, water distribution network (WDN) for instance is not ensured by the utility company right to the customer's home. They can only install the customer's water meter at a maximum distance of 50meters from the main network [2]. Then, the customer has the responsibility to extend the piping from his utility water meter to his premises. This extension of the network is hardly done following regulations and is with poor pipe quality which brings severe water waste. The same waste can be remarked in some developed countries. For example, at London in UK, 589 million liters water are lost per day due to the leakage, which is about 1/4 of its overall daily water supply [3].
Giving the above-mentioned situation of drinking water in developing countries in general and in Buea city of Cameroon in particular, the application of Internet of Things paradigms and of RF communication for a better WDN is proposed in this paper. Parameters such as water consumption values and flow rate, peak period values, pressure requirements and physical pipe properties can then be easily monitored. This proposed system also helps to accurately determine how frequently and where water is used by residents in their homes, allowing a more proactive approach to water demand management and infrastructure planning. In addition, water utility company in Cameroon faces the problem of readings from water meters that need to furnish accurate and right consumption and thus avoid customer dissatisfaction [4]. This paper is organized so as to cover in section two the review of water meters and reading techniques. A proposed global system architecture and system components cover respectively section three and section four. Simulation results as well as implementation, tests and results of the system are presented in section five. Some considerations about the energy consumption of the RF part are given in section six. The conclusion and future challenges of this work are presented in section seven. Figure 1: Water withdrawal as a percentage of total available water [1]

Review of water meters and reading techniques
A water meter is a device that collects and registers information on the volume of water (in gallons, liters or cubic meters) used over a period at a particular location of the WDN [5]. The resultant information is used to calculate the amount to be charged by the water utility to the customer for water consumed during that period. A methodology and technology for reading water meters has evolved greatly since the 1980's, producing major improvements in the technology and concomitant increases in the quantity and quality of the information collected. Water meters have thus evolved from standalone devices to networked devices working sometimes in a complex sensor network providing information services. We can then note reading methods such as Eyeball, Walk-by, Drive-by, Fixed Network, smart water meter.

The Eyeball
This legacy method requires a meter reader to physically access the node location and read the meter. This information is then manually input into the utility 's system database for evaluating and/or calculating the charge for water usage of that billing period. Since this method is labor-intensive and expensive, such readings are at most made only quarterly, but monthly in some places like Cameroon [6][7]. This information is usually more than sufficient for calculating the portion of the water bill for that location; but it does not detect leaks, inaccurate measurements from water meter and unbalance community use of water [8].

Walk-by
The meter is connected with wires to a device located outside the building; so even though a physical visit by a meter reader is still required he does not have to enter the building, eliminating the problems caused by lack of access to the meter. The meter reader uses a handheld computer, which receives the information via infrared or radio frequency or touches the handheld with the device equipped with the meter. The handheld computer records the water usage information for a later uploading to the meter billing system. While this method reduces human error in the transcription, it does not have the possibility of detecting computer error if the protocols in the handheld computer and in the billing system software are not compatible [8]. In addition, it does not detect leaks, inaccurate measurements from water meter and unbalance community use of water [8]. Walk-by is not applicable in Cameroon case where almost all water meters are at distances of about 300m to a km from houses.

Drive-by
Here the meter is retrofitted with, or already comes with a radio frequency transmitter; the meter reader in his vehicle reads that as he drives past all the metered buildings on his route. The information is collected on a laptop in the vehicle, which has a software that matches the account information and prepares it for download to the billing system when the vehicle returns to base. Drive-by is usually employed on rural routes that are not cost effective [8]. As the above techniques, drive-by does not detect leaks, inaccurate measurements from water meter and unbalance community use of water [8].

Communication Network and water meter reading a -Fixed Network
The fixed network is what we usually think of when we talk about automatic meter reading. This implementation takes the full use of the capabilities of the wireless water meter and enables it to become a network sensor node for the water utility that can allow almost continuous water usage readings for a number of purposes. In the fixed network the signals from the single meter are transmitted and then collected in a central receiving station, if close enough, or to repeaters and then to the central receiving station [9]. In most of cases, a star topology is used, but in some implementations, a mesh topology is used where each meter can act as a repeater for any others within the range.

b -Wireless Senor Network
The wireless communication options for automatic reading of water meters include the short range RF, the Global System for Mobile (GSM) communications, the Worldwide Interoperability for Microwave Access (WiMAX) and the Long Term Evolution (LTE) [10]. Detailed comparisons between the various communication technologies used for automatic meter reading applications have been performed. These comparisons found that each technology has unique advantages but also has resulting disadvantages. High data rates can be achieved but drive up the cost [10][11]. Solutions like ZigBee technology are used in applications such as home automation, remote monitoring, and smart lighting; ZigBee is based on the IEEE 802.15.4 specification [11]. ZigBee based designs are popular in the smart utility field because of low power consumption and cost-effectiveness [12][13][14][15]. An example of a smart metering system for a power utility company was built in Malaysia [12]. This system uses a ZigBee module attached to each meter to transmit measurements to a collector node that then uses GSM to send data to a central computer for processing. This system uses a mesh network topology to allow meters too far away from the collector node to transmit their data to nearby meters for forwarding to the collector node. This approach increases the effective coverage range of the collector node. However, the collector node is a bottleneck, as well as a single point of failure given that all data needs to flow through this node in order to reach the central computer. Another smart water meter system uses an IEEE 802.15.4 compliant RF module to send data from the smart water meter to a gateway device [6]. The gateway runs a Real-Time Operating System (RTOS) known as Contiki-OS with IPV6 over Low Power Wireless Area Network (6LoWPAN ) support. The data is then sent to a back-end system for analysis and display. Collected data is displayed using a web interface as well as using a monitoring tool like Pandora FMS [6]. While the well-designed systems would cater for a constant communication between the transmitting and the receiving point, some of them make use of their local service providers [12,16,17]. In such system, dependency is highly prevalence and as such, communication can be incapacitated if the service provider has a problem. We seek to address that by creating an RF communication network which is free of cost and free of dependency from any second party, hence increasing reliability. Figure 2 is the proposed general architecture illustrating the global functioning principle of the system. Basically, the water flow sensor output signal goes to the microcontroller board Arduino for data extraction and serial encoding. The serial output from the encoder is fed to the data input of the RF transmitter for transmission to both utility LAN and client receiver module. At the client receiver end, the serial data from the RF receiver are decoded by a microcontroller board Arduino. The processed data is then displayed with the help of an LCD. But at the Utility LAN unit, data is sent to the internet server where the utility company can access for billing and decision making.

Water flow sensor
The Water flow sensor of Figure 3 consists of a plastic valve body, a water rotor and a hall-effect sensor [18]. Rotor rolls when water flows through. Its speed changes with different rate of flow. The hall-effect sensor outputs the corresponding pulse Signal.

RF modules and dedicated microcontroller
Among considerations to take into account while choosing the transceiver module, we have the communication range which in theory is greater than 100 meters for the module TX/RX-433 MHz we considered in this system; that range is convenient for our application. Moreover, this transmission is very easy to implement and allow a low power consumption in standby mode. The main drawback is the absence of a real communication protocol (as implemented in the case of other concurrent solutions such as Bluetooth low energy, Zigbee, Lora, Sigfox, etc.…) which will bring inherent transmission collisions. Figure5-(a) presents that TX/RX-433MHz RF transceiver module [19]. The transmitter draws a very low power when transmitting logic zero while fully suppressing the carrier frequency thus consume significantly low power in battery operation. When logic one is sent, the carrier is fully on to about 4.5mA with a 3volts power supply [19]. The data is sent serially from the transmitter which is received by the tuned receiver. The TX/RX-433 MHz module comes with internal data decoding circuit and decoding software; no additional circuit is needed to perform signal input and data output. The transmitter and the receiver are duly interfaced to two Arduino Uno microcontrollers board based on the ATMega328 for data transfer [20]; Figure5-(b) is a view of that Arduino Uno microcontrollers board.

Wi-Fi (ESP8266) Module
The primary objective of the Wi-Fi (Wireless Fidelity) module Esp8266 of Figure6 is to transmit wirelessly the data got from the flow rate sensor to the Cloud based Server. The Wi-Fi module uses the mobile network radio waves for easy access to the internet. The Esp8266 has an Inbuilt TCP/IP protocol and AT commands are used to connect it to the Internet. A Baud rate of 9600 is maintained for its communication with the microcontrollers ATMega328.

Internet Server
The Web server acts as the server and performs data processing within the web databases. Web server receives and stores the water flow rate data sent by Esp8266 Wi-Fi module at given time. We focus on the ThingSpeak application program interface (API) which provides simple communication capabilities to objects within the IoT environment, as well as interesting additional applications (such as ThingTweet). Moreover, ThingSpeak allows you to build applications around data collected by sensors. It offers (near) real-time data collection, data processing, and also simple visualizations for its users. Data is stored in so-called channels, which provides the user with a list of features [22]. Each channel allows you to store up to 8 fields of data, using up to 255 alphanumeric characters each. There are also four dedicated fields for positional data, consisting of the description, the latitude, the longitude and the elevation. All incoming data which is time and date stamped receive a sequential ID. Once a channel has been created, data can be published by accessing the ThingSpeak API with a 'write key'; the 'write key'isa randomly created unique alphanumeric string used for authentication. Consequently, a 'read key' is used to access channel data in case it is set to keep its data private (the default setting). Channels can also be made public in which case no read key is required. According to the ThingSpeak website, the API works as noted in Figure7. Essentially, 'things' are objects that are given sensors to collect data. Data is sent and received via simple "Hypertext Transfer Protocol" (HTTP) POSTs, much like going to a web page and filling out a form. Figure 7: ThingSpeak represented as 'Cloud' Interface [22].
The data is then uploaded to the cloud and from there it can be used for a variety of purposes. In turn, data (such as commands or choose of options) can be gathered and communicated to the cloud which sends them to the object. When a device sends data through a HTTP request (communication), it is processed by the IoT service (in this case ThingSpeak), which communicates with a virtual server. Both the server and the IoT service communicate directly with the application. For this work, we take the case of connecting a water monitoring system to the ThingSpeak web service whose data will be logged to a particular channel.

Client Web Interfaces
The client will be accessing the web page on the web server to have his real water consumption as per utility company point of view; only specific client can get permission to access the page. The page will contain the chart of the water flow through the pipe and will be also automatically updated/displayed within specific time intervals. The client can also see the data of the previous water flow on the page.   Wi-Fi system data transmission is also simulated and results presented in Figure 9; transmitted information is properly received at the virtual terminal and will be exploited and displayed in any desired form like graph in a real time environment. Figure 9: Simulation results of Wi-Fi system data transmission

System implementation and results
In addition to the above presented hardware materials, Web-enabled measurement systems as well as corresponding software facilities have been used. Figure 10 and Figure 11 are the test results and present respectively the dashboard implemented for the utility company exploitation and the real time transmitted information at the client end. The administrators can get water consumption information from the various remote flow sensors and access the information from the web at any time through Internet. The transmitted information for the customer is mainly the flow rate ("F_R" which stands for flow rate as seen on LCD screen of the prototype) and the cumulated water consumption for a given period of time ("T_Vol" which stands for total volume as seen on LCD screen of the prototype). The flow is used to track water leakage since any flow without opened tap at home indicates that there is a leakage after the meter. For a better water consumption follow up, the system is programmed to alert the owner after he had exceeded a desired consumption limit entered for a day. The real time water consumption is plotted at the utility server. On the same graph of Figure 10, the monitor also has a real time geographical water distribution of an entire area; any water leakage or water misuse can be easily identified and necessary measures taken. This geographical overview of the water distribution in the city will also help to identify area with no water in the piping; as a matter of fact, if no water consumption is recorded in an area for a certain period of time, that will just mean there is no water in the piping there. For such cases, the problem can be easily located with the help of this proposed geographical localization and solved.

Energy consumption measurement results
In order to make realistic assumptions about the energy fingerprint of the radio transmission part, a simple point-to-point communication platform was set up. More precisely, by using two Arduino boards and two 433 MHz modules (MX-FS-05V as emitter and MX-05V as receiver), random data was conveyed between the two microcontrollers while measuring the energy consumption of the radio front-ends. The radio transmission quality was quantified by performing real-time measurements on the "baseband" time domain signals at the emission and at the reception. The measurements have been done by using a Key sight's DSO9064A oscilloscope. An example of such measurements is given in Figure 12. Indeed, Figure 13 presents the emitted (upper signal) and the received (bottom) "baseband" waveforms. In this case, random data was sent by frames with a data rate of 8kbits per second. Complementary to these measurements, the spectrogram of the emitted signal was recorded, by using Agilent's E89605B, E2731B and E1439C vector signal analyser system. The distance between the emitter and the receiver modules is set to be very low (less than a meter) such way that no transmission errors are appearing. The spectrogram of the emitted signal, centered at 433.87MHz is presented in Figure 13. It was recorded during 13.17 seconds and is showing the spectrum range of the emitted OOK (on-off keying). The different frames are sent each 500 ms and their duration is function of the payload. Moreover, the instantaneous power consumption of the RF front ends was measured by using two precision multi-meters. Under these conditions; the measured instantaneous power consumption at the receiver side was of 250mW and is independent on the variation of the received signal parameters. On the contrary, the power consumption at the emitter side depends on the transmitted signal's state. More precisely, during the frame transmission; an average DC power consumption of about 250 mW was measured while the average power consumption level decreased to 6μW during the periods between two frames. These values are decreasing with the decrease of the data rate such that for 1kbit per second, the consumed DC power is decreasing to 13.4 mW during the frame transmission.

Conclusion
In this paper, we investigated and proposed a solution to some of the challenges faced by water utility companies and their customers in most developing countries. The proposed solution has a number of benefits including a real time follow up of water consumption by customers, a real time geographical situation of the WDN for an equity water distribution and easy leakage detection; access by the client to data of his consumed water at both client and utility company server permit an effective water consumption billing. The paper also aims through the above-mentioned benefits at spreading an awareness regarding the uncontrolled and ineffective means of supplying and using water resources; this help to reduce the practice of casual wastage of water. This paper aimed at bringing a functioning solution to this above critical issue of WDN for Cameroon context. Some improvements need now to be brought up; among them we can highlight the energy supply source for water meter node; the technology used at that node should be low consumption as much as possible; the harvested energy from the WDN can be explored as a possibility for recharging the water meter node supply batteries. In this perspective, a proper choice of the microcontroller solution and of the transmission data rate will be done in order to minimize at maximum the energy consumption and to envisage a battery free connected water meter solution.