## 3 System Architecture, Software Services and Deployment
### Fog Computing-Based Data Processing Hierarchy  
When viewed in an abstract perspective in terms of data processing, the entities of the system can be organized into two logical layers: (i) the Sensors and Actuators Layer (SAL), comprised of the smart devices physically attached to the source of monitoring that collect the information, digitize and transmit it, and (ii) the Processing layer (PL), comprised of all the system entities that convert received bits of information into meaningful datasets. The second layer is organized into additional sub-layers based on their processing ability and the communication interface they support. From a fog computing perspective, as presented in Figure 2,  
Figure 3: A hierarchical network architecture based on LPWAN and wM-Bus. processing nodes reside in the edge/fog computing layer, while the backend layer hosts all cloud services of the prototype. This design inherently exploits the existing intermediate layer between the smart water meters and the cloud, while at the same time, the approach of having all available cloud services deployed in large backend data centres alleviates several scalability concerns along with bandwidth consumption problems, thus ensuring the seamless operation for the whole prototype. The prototype architecture blueprint is presented in Figure 4.  
As shown in Figure 4, the Sensing and Actuation equipment Layer (SAL) contains all the smart water sensing and control equipment, which can be off-the-shelf (i) water consumption meters, (ii) water pressure meters or (iii) remote-controlled valves. These devices broadcast their sensing data via wM-Bus over predefined time intervals and provide metrics related to (i) total water consumption, (ii) current water pressure, (iii) water and environment temperature and (iv) water valve status. The first node equipped with data processing, storage and analysis capabilities is called the Mox node, located in the Edge-based Processing sub-Layer A (EPL-A) and interlinked with a bridge that can deliver transmitted packets for local processing through wM-Bus and LoRaWAN interfaces. Mox nodes have limited available computational resources, provide only basic data manipulation functionality and can only be used for elementary tasks. Designed for operating on resource-scarce hardware, Mox nodes integrate a trimmed-down version of the analytics software deployed in full scale into other nodes of the prototype and are therefore capable of obtaining and efficiently handling metrics from just a small number of sources. One could state that their main function is to collect packets from the smart devices, identify the source of each message and prioritize its upload to a higher capacity node located in a different layer than EPL-A. Moreover, Mox nodes can be used for remotely controlling smart meters and valves, which supports this type of functionality. Given the fact that all transmitted messages are encrypted, Mox nodes incorporate authentication mechanisms. However, due to their limited computational capacity, as well as the static topology in which they tend to operate having only specific smart water metering devices interlinked, authentication is carried out using pre-existing permanent keys, each directly related to an existing sensing node (see Section 3.1). Data that are not processed with the Mox nodes are transferred for further processing into different, more capable nodes of the prototype, through the LoRaWAN interface, and are picked up by the LoRa gateways available in the area. After this point, messages reach the Tergo nodes, which form the so-called Edge-based Processing sub-Layer B (EPL-B) together with the affiliated LoRa gateways. Figure 4: The fog computing-based data hierarchy. Tergo nodes have significantly improved computational capacity as they operate on better hardware than the Mox nodes and thus support a wider variety of features by integrating an almost full version of the analytics software deployed in the prototype.