Smart Meter infrastructures are emerging systems that measure, collect, and analyze utility data and communicate with the network's backbone on a xed schedule. Such infrastructures are a vital part towards real Intelligent Cities. In this article we propose an edgeprocessing oriented Internet of Things architecture for smart meter networks that helps reduce data communication while keeping the system secure, reliable and responsive. We discuss our system architecture based on a real-world water metering deployment of 48 water meters inside a University Campus, using o -the-shelf wM-Bus water meters. We also provide a study of how our solution can face the same problems regardless of the size of the water meter network, scaling up to cities of millions of citizens and measuring points, reducing tra c and data sizes event by 80%.
Copyright c 2019 for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
Edge computing is a contemporary platform which deploys an intermediate layer of computational and storage
resources paired with the necessary control functionality between end-user equipment and cloud computing
datacenters. The edge infrastructure's physical proximity with the IoT sensors, greatly limits latency, decreases
bandwidth consumption and delivers cutting-edge services of improved security and reliability. This approach
extends the cloud computing paradigm by migrating data processing closer to production site, accelerates system
responsiveness to events along with its overall awareness, by eliminating the data round-trip to the cloud.
O oading large datasets to the core network is no longer a necessity, consequently leading to improved safety
and quality of experience (QoE) [
Smart City-related applications become more and more common as well as pervasive, leading to an increased sensing node deployment density and network topology scale. Mostly depending on Low Power Wide Area Networking (LPWAN), an emerging network paradigm for IoT, Smart City monitoring infrastructure must remain low cost, energy e cient and capable of being widely deployed. Among all available LPWAN technologies, LoRa networking has attracted much attention from both academia and industry, since it speci es an open standard and allows the development of autonomous LPWAN networks, eliminating the necessity for proprietary hardware. This paper proposes a Smart City monitoring application which exploits speci c characteristics of Edge computing and LoRa to provide a solution to address a real-world problem: water management misuse. This thorny issue is tackled through an intelligent platform that analyzes inbound water meter oriented datasets on the spot, while retaining an increased level of robustness and expandability. 2
The IoT domain is always challenging due to the large potential number of sensor data that can be generated by
an ever increasing number of sensing devices. Typically, the sensor devices are low-end but the idea of combining
data close to their producers (i.e., in-network aggregation and on-the-spot data management) is considered a
viable solution. The main advantage is more clear by the ability to combine heterogeneous datasets from multiple
sources and with low latency, providing a better experience of end-users[
The arrival of Big Data solutions, with the help of the map-reduce technique provided us with multiple tools
[
Complementary to sensor-originating tra c management and dataset handling, precise energy monitoring and
conservation methods are aspects of great interest, mostly due to the imbalance between power generation and
demand. Smart Grids [
The notion of local data pre-processing to reduce data transfer between nodes was considered by [
The evaluation setup consists of 4 layers. The lower layer, contains a total of 44 o -the-shelf water consumption meters, 2 water pressure meters and 2 remote controlled valves deployed inside a University Campus. All the above broadcast their data using wM-Bus on prede ned intervals (between 3 and 60 minutes depending on the device's con guration). The data reported include the total water consumption, the current water pressure, the water and environment temperature and the status of the water valve. Each message is encrypted individually and requires a separate (per meter) key to decrypt its data on the receiving end. The transmitted packets are collected by a network of 18 deployed wM-Bus-to-LoRaWAN bridges based on the STM32 Nucleo processor5. This is the second layer of our deployment. Each bridge is responsible for receiving packets from a subset of the deployment's devices based on proximity. The collected packets are then transmitted, without any attempt to decrypt them, to the LoRaWAN where they are picked up by the LoRa gateways available in the area. The LoRa gateways together with the LoRa Server and the edge processing services form the 3rd layer of our setup, with devices based on the Raspberry Pi6 single board computer. In this layer the received packets are decrypted and decoded based on the packet format de ned by the meter's manufacturer. Above all that, the 4th layer consists of the cloud services that nally collect all the data from the whole infrastructure and provide APIs and interfaces for accessing the collected data.
Our edge analytics platform is split into two parts, the edge-1 and edge-2 levels. The edge-1 level is capable of communicating only with a limited number of devices, due to its low computation power (1-6 water meters). Its main job is to collect packets from the water meters, identify the source of each message and prioritize its upload to the higher layers of the system, as well as control of the remote controller valves.
On top of that, the edge-2 level possesses much more capable devices that can process and analyze a lot more data. The edge-2 processing services include: 1. A service for analyzing incoming packet rates and the signal quality from the installation's meters. 2. A key management service for storing and accessing the meter's decryption keys.
In the rest of this paper, we focus on the operation of components 1 and 3 to showcase the real-time analysis of the incoming data packets from the water meters installed. The analysis of the data is done using Apache Flink7 on the low cost Raspberry Pi single board computers. For analyzing the incoming packet rates, our goal is twofold. On the one hand, we want to nd irregularities in the reported data (i.e., water consumption, ow and pressure) from each meter and on the other hand we try to ll in missing sensor data due to problematic communication between the water meter and the bridge devices of the installation. Based on the irregularities we nd we can decide whether the data collected are going to be directly delivered to the cloud services of our system to produce any kind of alerts or noti cations to the users and administrators of the system or they are going to be collected to be sent later on the day. For the analysis of sensor data in the cloud services we need to generate aggregated metrics on the water consumption and the water pressure reported on di erent time granularities. All operations are implemented using Apache Flink Stream Analysis. 4 4.1
wM-Bus data packets The data transmitted by the water meters and the rest of the devices in our deployment follow the speci cation de ned by the wM-Bus protocol [1]. Each meter transmits periodically a single wireless frame that contains 5https://www.st.com/en/evaluation-tools/stm32-nucleo-boards.html 6https://www.raspberrypi.org/ 7https:// ink.apache.org/ two parts. The header part is unencrypted containing information about the device's identi er and the format identi er of the encrypted data. The payload part is encrypted using a unique key for each device. Once decrypted, this part depending on the format de ned in the header can contain information about the water volume measured, the water ow, the temperature of the water and the environment as well as alarms about the valve's status (e.g., whether someone has tried to tamper with it or physically tried to stop the measurement). Each meter transmits di erent packet formats at prede ned intervals that range from 3 minutes to 1 hour, plus some randomized o set due to clock drift to avoid collisions. Packet transmission events from two water meters by two di erent manufacturers are presented in Fig. 2. As we can see the rst meter presented on the left broadcasts messages much more frequently than the second one while the contents inside the packets follow the same format. 4.2
To generate analytics on the packet rates and signal quality, the system generates for each packet the time interval since the last one received and its received signal strength indicator. For these metrics, it then computes its average and standard deviation statistics. Using this, the system can detect whether the currently reported time interval (or signal quality) is normal or not based on the assumption that a value in the [avg 2 std; avg + 2 std] is considered acceptable. These abnormal values are called outliers and are dropped from any further processing while a noti cation is generated for the system administrator to indicate an unhealthy of the deployment. The data that are valid are used to adapt the calculated average and standard deviation values to incorporate cases where the average time interval of the packet reception changes over time. Outliers on the signal quality indicate that a device while operating and transmitting data for the moment could be facing a problem in the future as its signal is degrading due to environmental reasons or any external interference. 4.3
The analysis of the sensor and meter data is the target of the whole operation of our system. In this case, we do not need to exclude data from further analysis since the data reported from the meters are trusted as accurate but we need to generate alarms for our end users if the received data deviate from the expected behaviour of the meter (consumer). For example, detecting an abnormal water ow, much higher than normal, could indicate a broken pipe that needs to be xed and could incur unexpected charges on the nal client. 5
To conduct our evaluation we used the data from our real-world deployment and scaled it up to reach the
conditions to be faced in fully edged Intelligent City installations of di erent sizes. The deployment would
be much more dense and the total generated data could exceed the processing capabilities of a single cloud
infrastructure. To get estimates on how many devices could actually be deployed in a real world city we follow
the categorization provided in [
Test Site Small Medium Large XLarge XXLarge
Population Limits
between 50000 and 100000 between 100000 and 250000 between 250000 and 500000 between 500000 and 1000000 between 1000000 and 5000000
Water Meters
48 between 27000 and 54000 between 54000 and 135000 between 135000 and 270000 between 270000 and 540000 between 540000 and 2700000
In our evaluation setup a total of 3000 packets are received by all the deployed meters every day. These packets generate multiple measurements but for the rest of our evaluation we will keep referring to the number of packets instead of the sensor measurements for simplicity. To scale this number from our evaluation setup to the city categories we start to see the bene t of using such a distributed processing infrastructure. The expected packets per day and data sizes are available in Table 2. We use the lower estimates for the number of deployed water meters in each city category to calculate the number of expected packets and data sizes. As we can see even from a small city with a population of 50000 and 27000 water meters to collected data exceed 13GB, a load big enough for any network or processing infrastructure. 5.1
Pre-processing each message directly on the cloud requires establishing or maintaining a communication channel with constant data ow from the edge devices of our system to the remote cloud infrastructures used. Such a connection is not the best option especially when communication is done over metered connections (e.g., a 5G network).
On the contrary, we chose to do the data pre-processing on the edge devices already available in the installation (Raspberry Pis running the LoRa server software). Running the analysis on the same amount of data on the 8https://www.eydap.gr/en/TheCompany/Water/DistributionNetwork edge takes signi cantly more time, around 30 seconds (vs 3.5 seconds in the cloud server) but saves a lot of the generated tra c. Using this method, we can combine multiple packets over larger time intervals and transfer them, all together in a compressed format to the cloud. Due to the repetitive nature of the collected data, compressing them could result in huge gains over the nal size of the data that needs to be uploaded. Also, due to our edge pre-processing, we can identify situations when there is a need for urgent communication and trigger an immediate upload of the data collected so far. As seen in Table 2 the size of data that needs to be uploaded to the cloud every day reaches a total of 24 M B. Compressing the data could save up to 80% on data to be uploaded in total, every day when no immediate uploads are required leading to much more important gains in larger scenaria. 6
This paper presented the properties of a real world smart metering solution combined with an edge processing and analytics solution for collecting and analyzing the data produced in the edge of the network. Our solution uses the intermediate layer between the IoT deployment and the cloud services deployed in large datacenters to alleviate a series of issues in the areas of scalability, bandwidth consumption reduction while providing seamless operation for the whole system. Then based on the data from real world water metering networks, we estimate the amount of data a fully edged smart city solution will need to handle, showing how our solution ts in the bigger picture. [1] Communication systems for meters.
communication/data/en-13757 en, accessed: 2019-09-06 https://ec.europa.eu/eip/ageing/standards/ict-and[2] Akrivopoulos, O., Amaxilatis, D., Chatzigiannakis, I., Tselios, C.: Enabling stream processing for peoplecentric iot based on the fog computing paradigm. In: 2017 IEEE 22nd International Conference on Emerging Technologies and Factory Automation (ETFA). pp. 1{8 (Sept 2017). https://doi.org/10.1109/ETFA.2017.xx [3] Akrivopoulos, O., Chatzigiannakis, I., Tselios, C., Antoniou, A.: On the deployment of healthcare applications over fog computing infrastructure. In: 2017 IEEE 41st Annual Computer Software and Applications Conference (COMPSAC). vol. 2, pp. 288{293 (July 2017). https://doi.org/10.1109/COMPSAC.2017.178