Next Article in Journal
Robust and Accurate Wi-Fi Fingerprint Location Recognition Method Based on Deep Neural Network
Next Article in Special Issue
Privacy-Preserving Lightweight Authentication Protocol for Demand Response Management in Smart Grid Environment
Previous Article in Journal
Towards Low-Cost Pavement Condition Health Monitoring and Analysis Using Deep Learning
 
 
Font Type:
Arial Georgia Verdana
Font Size:
Aa Aa Aa
Line Spacing:
Column Width:
Background:
Article

On the Use of LoRaWAN for the Monitoring and Control of Distributed Energy Resources in a Smart Campus

by
Marco Pasetti
1,*,
Paolo Ferrari
1,
Diego Rodrigo Cabral Silva
2,
Ivanovitch Silva
3 and
Emiliano Sisinni
1
1
Department of Information Engineering, University of Brescia, 25123 Brescia, Italy
2
School of Sciences and Technology, Federal University of Rio Grande do Norte, Natal 59078-970, Brazil
3
Digital Metropolis Institute, Federal University of Rio Grande do Norte, Natal 59078-970, Brazil
*
Author to whom correspondence should be addressed.
Appl. Sci. 2020, 10(1), 320; https://doi.org/10.3390/app10010320
Submission received: 4 November 2019 / Revised: 13 December 2019 / Accepted: 16 December 2019 / Published: 1 January 2020
(This article belongs to the Special Issue Communication System in Smart Grids)

Abstract

:
The application of the most recent advances of the Internet-of-Things (IoT) technology to the automation of buildings is emerging as a promising solution to achieve greater efficiencies in energy consumption, and to allow the realization of sustainable models. The application of IoT has been demonstrated as effective in many fields, such as confirmed, for instance, by the Industry 4.0 concepts, which are revolutionizing modern production chains. By following this approach, the use of distributed control architectures and of IoT technologies (both wired and wireless) would result in effective solutions for the management of smart environments composed of groups of buildings, such as campuses. In this case, heterogeneous IoT solutions are typically adopted to satisfy the requirements of the very diverse possible scenarios (e.g., indoor versus outdoor coverage, mobile versus fixed nodes, just to mention a few), making their large-scale integration cumbersome. To cope with this issue, this paper presents an IoT architecture able to transparently manage different communication protocols in smart environments, and investigates its possible application for the monitoring and control of distributed energy resources in a smart campus. In particular, a use–case focused on the integration of the Long Range Wide Area Network (LoRaWAN) technology is considered to cope with heterogeneous indoor and outdoor communication scenarios. The feasibility analysis of the proposed solution is carried out by computing the scalability limits of the approach, based on the proposed smart campus data model. The results of the study showed that the proposed solution would be able to manage more than 10,000 nodes. An experimental validation of the LoRaWAN technology confirms its suitability in terms of coverage and latency, with a minimum LoRaWAN cell coverage range of 250 m, and a communication latency of about 400 ms. Finally, the advantages of the proposed solution in the supervision and management of a PV system are highlighted in a real-world scenario.

1. Introduction

Since the invention of the thermostat by Warren Johnson in 1883, mankind dreams of intelligent and automated environments. When applied to buildings, the possible applications of this concept are countless: from the improvement of the safety and the comfort of occupants, to the application of energy efficiency measures, and the care for the disabled and the elderly, just to mention a few [1]. Among these, energy efficiency has become one of the most important aspects in the design and management of both residential and commercial buildings [2], also following the increasing concerns on global warming and on fossil fuels depletion. In particular, when it comes to non-residential sites, such as, public agencies, commercial, and industrial buildings, the concept of energy efficiency has an even greater bearing, by dealing with larger amounts of heterogeneous users, equipment, and facilities. This in fact implies larger opportunities of energy savings, which in the case of public buildings, may be particularly critical, due to the use of public money.
The efficient use of energy intensive equipment, such as Heating, Ventilation, and Air Conditioning (HVAC) systems, plays a key role for the development of sustainable energy buildings. It is worth noting that this applies not only to the design stage, i.e., by making use of high performing insulating materials, advanced construction technologies, efficient equipment, or renewable sources [2,3], but also to the operation stage, i.e., by defining how equipment and energy resources must be operated to ensure an efficient use of energy [4]. The efficient operation of equipment and energy resources, particularly in the case of large buildings, requires the monitoring and control of several parameters, concerning the use of facilities (i.e., the presence of users, the thermo-hygrometric conditions in rooms, etc.), such as well as the working condition of devices and equipment [5]. In this context, the recent diffusion of Information and Communication Technology (ICT) solutions and, in particular, of the Internet of Things (IoT) paradigm, allowed the development of the smart building concept [6], which is opening the way for improved energy management capabilities, thanks to the use of advanced monitoring and control functions over heterogeneous sensors and devices [7,8].
Of particular interest is the application of such functionalities in complex systems, such as campuses, where the coordinated monitoring and control of clusters of buildings and dispersed resources is required to implement the optimal management of the whole system. In this kind of applications, distributed and holonic control architectures are suggested by the scientific literature, by following the recent research trends in the monitoring and control of Distributed Energy Resources (DERs) in Smart Grids [9]. In particular, decentralized control architectures inherited by smart and micro-grids management systems [10,11] have been proposed as viable solution also in smart campus environments, such as suggested in [12,13].
The application of advanced monitoring and control strategies (and of the related ICT solutions) relies on the availability of proper communication infrastructures. The complexity and the installation costs of proper communication systems represent one of most critical aspects of such application. The installation of wired systems, such as optical fiber in large areas (e.g., where distances are on the order of hundreds of meters) or ethernet networks in small areas (e.g., where distances are below 100 m) may present relevant costs, particularly in old buildings or in complex scenarios, such as that of smart campus, where the distance between buildings may be up to dozen or even hundreds of meters. For this reason, the use of wireless networks are gaining momentum, particularly when large area or hybrid environments are taken into account. Usually, Local Area Network (LAN) technologies like IEEE802.11 (WiFi) are used inside buildings, leveraging previously deployed infrastructures. On the other hand, the use of performing wireless technologies, such as WiFi, presents coverage capacity limitations, both in indoor environments (i.e., between different stories of the same building) and in outdoor scenarios (i.e., between different buildings). Last, the use of Power Line Communication (PLC), which makes use of existing electrical infrastructures inside buildings, can be successfully implemented only on the same portion of the electrical network, by thus limiting its application only to very simple user systems. When it comes to more complex systems, such as a campus, a mixed scenario with multiple buildings and external areas is more realistic, leading to consider a Wide Area Network (WAN) approach. In particular, the use of Low Power Wide Area Network (LPWAN) solutions is emerging as a viable option, thanks to their large coverage, low complexity and low power consumption. The use of the LoRaWAN technology could thus represent a very promising solution, due to its good coverage capabilities (both in outdoor and in hybrid environments), whereas its most critical aspect is represented by the relative low data throughput and duty cycle limitation. In addition, the adoption of heterogeneous IoT protocols and devices may present relevant issues, making their large-scale integration cumbersome.
Even if the LoRaWAN technology may well fit this kind of application, its main drawback is represented by the limited data throughput, which makes its application questionable. Starting from this remark, in this study we try to answer the following questions:
  • is the LoRaWAN technology able to handle the amount of data and the refresh time intervals required for the monitoring and control of distributed energy resources in a smart campus?
  • how many devices can be monitored and controlled by a single LoRaWAN gateway?
  • can the LoRaWAN infrastructure be integrated as complementary solution in an existing monitoring and control architecture?
To answer the first question, we analyzed the scientific literature to identify the monitoring and control architectures proposed for the management of distributed energy resources in complex systems. A generalized architecture was thus determined, and then used as reference architecture to determine the refresh time intervals and the type of messages exchanged between the different intelligent devices and the related supervisory entities. Secondly, a proper data model structure was defined to allow the computation of the payload of the communication. It is worth to note that, to the best of the authors’ knowledge, the detailed definition of a smart campus use–case, and of the related data model, were never presented in the literature, thus making this contribution part of the novelty of this study. Finally, a proper architecture based on the LoRaWAN class A technology was proposed, and its feasibility was evaluated by verifying its ability of transmitting the required amount of data in the given refresh time intervals. The evaluation is carried out by computing the Time-on-Air duration of monitoring and supervisory control messages. Starting from the results obtained above, we answered the second question by computing the number of devices that can be handled by a single LoRaWAN gateway. The computation has been carried out by considering two different scenarios: a worst case scenario, where each installed device operates with the maximum expected payload, and a realistic scenario, composed by a mixed set of simple sensors and complex devices operating with the expected average uplink and downlink payload. Last, to answer the third question, we proposed an IoT architecture able to transparently manage different communication protocols. The proposed architecture operates only at the application layer, thus not involving the implementation of specific communication techniques. The latter are indeed provided by the LoRaWAN infrastructure, without requiring any modification or custom implementation. Finally, for sake of completeness, the experimental validation of the technical suitability of a LoRaWAN implementation is provided in the appendix, by presenting the results of the coverage and latency measurements carried out in the main campus of the Federal University of Rio Grande do Norte, Brazil.
The structure of the paper is organized as follows. In Section 2, the application of distributed control architectures in smart campus environments is briefly discussed, by focusing on the distributed management of energy resources and on the role of IoT and LPWANs. Section 3 describes the proposed IoT architecture integrating LoRaWAN. In Section 4 the scalability analysis of the proposed architecture is presented, by first introducing the smart campus use case, and the related data model. Finally, in Section 5 the results of the study are summarized and the final remarks are discussed. In the Appendix A the LoRaWAN technology and some of its available implementations are discussed together with the real scenario experimental validation in terms of latency and coverage.

2. Distributed Control and IoT Architectures in Smart Environments

The scenario where objects, sensors and actuators are communicating to each other to form an automated place is called smart place. Depending on the context, the application of automation and of the related ICT solutions can lead to different scenarios, such as a smart home, a smart building, a smart factory, a smart campus, or even a smart city. Each of these environments is characterized by specific features and requires different control approaches. While in a smart home, for instance, the physical structure is composed by a limited number of spaces (e.g., some rooms), appliances and equipment, a smart campus is formed by many different areas. University campuses are in fact formed by sectors, blocks, classrooms, laboratories, offices, etc., each with different functions, equipment, and independent staff, thus requiring specific management capabilities. In this section, the recent research trends on the monitoring and control of distributed energy resources in complex systems are briefly discussed, by introducing decentralized control architectures, and discussing the role of IoT and of LPWANs in smart environments.

2.1. Distributed Management of Energy Resources

Several research streams recently dealt with the efficient operation of equipment and energy resources in smart buildings, by investigating different fields. Examples are the optimization of HVAC systems based on Model Predictive Control (MPC) algorithms or Neural Networks (NNs) [14,15,16,17], or the application of flexible control strategies, Demand Side Management (DSM) actions, and Demand Response (DR) programs [2,18,19,20]. The application of such control strategies is implemented in single family houses through the so-called Home Energy Management Systems (HEMSs), such as well as in large buildings, by means of Building Energy Management Systems (BEMSs). In the latter case, advanced control functions are usually defined by supervisory levels and then communicated to local controllers and actuators by means of local networks. Conversely, the implementation of DSM actions and DR programs, which involves the participation of third-party agents, such as Distribution System Operators (DSOs) or independent aggregators, requires the use of WANs [7,17].
The typical monitoring and control architectures usually implemented in smart HEMSs and BEMSs consist of two main layers: the control layer, and the supervisory layer. The control layer usually implements low-level monitoring and control functions over heterogeneous sensors and devices (equipment, appliances, gateways, and controllers). At this stage, different communication technologies are typically used: from field buses (such as BACnet or Modbus) to wireless protocols (such as WiFi, Z-Wave, ZigBee, or Bluetooth). At the upper-level, the supervisory layer is responsible for the supervisory monitoring and control of the whole system: it usually computes job schedules of distributed energy resources (from generators to loads and actuators), and then communicates this information to local gateways and controllers, which are responsible for the low-level implementation of the related control strategies. The supervisory layer is also responsible for the application of DSM actions and DR programs, by typically making use of WAN solutions. In this case, active power limitations are usually required for a given time period and communicated by third-party entities (such as DSOs or independent operators) well in advance [21].
When applied to smart campus environments, the application of coordinated monitoring and control functions over distributed resources (including isolated generators and equipment, such as well as entire buildings) requires the implementation of more complex architectures. In this case, decentralized control architectures can be adopted. Supervisory Energy Management Systems (EMSs) are in charge for the strategic coordination and scheduling of supervised devices and resources (from single equipment to entire buildings), by following system optimization objectives and by considering DR requests provided by external entities (i.e., smart grid operators). The schematic representation of such architecture is shown by the diagram of Figure 1. It is worth noting that an example of a real implementation of an EMS framework following this approach was proposed in [22].
Concerning the monitoring and control functions applied by the supervisory EMS, three main scenarios can be identified, according to aggregation level that can be implemented over the supervised resources. In its most simple formulation, sensors, generators, and electrical equipment can be directly supervised by the EMS. In this case, the supervisory control functions are implemented by computing the power generation and consumption profiles of generators and loads, respectively. Each power profile is defined as the active power produced or consumed by the specific physical entity over a given time horizon (typically 24 h) with a system-defined time step (usually 15 min). Power profiles are determined for all of the supervised entities by taking into account the users’ requests, weather forecasts, strategic schedules and constraints (set by the system administrator), historical data (used by machine learning algorithms), and current measurements from distributed sensors (i.e., current weather data, state of charge of storage units, etc.). For each physical entity, one or more profiles can be generated depending on the possible different configurations of the resource. HVAC systems, for instance, may have different feasible demand profiles, depending on the considered comfort levels and on time-shifting or peak-clipping options (implemented by means of thermal storage systems). In this scenario, power profiles are usually determined by the supervisory EMS, which is also responsible for determining the most suitable solution for each physical entity, and by then providing the related job schedules to the supervised resources. Typical job schedules are represented by temperature set-point profiles to HVAC systems, power limitation profiles to renewable generators, or chargedischarge schedules to electrical storage systems.
At a higher aggregation level, sensors, generators, and electrical equipment are not directly supervised by the EMS, but by local energy controllers (i.e., according to the power matcher concept [9]). In this case, power profiles are determined for each resource by local intelligent devices, and then aggregated as a class of net power profiles. Data from supervised sensors are used by local intelligence to evaluate the energy generation and demand of physical entities, but not forwarded to the upper supervisory layer (i.e., the EMS). The set of computed net power profiles are provided to the supervisory EMS, which is in charge for the selection of the most suitable net power schedule. Once selected, the net power profile selected by the EMS is forwarded to the local energy controller, which is in charge for ensuring that the given profile is accomplished, by properly controlling all the supervised entities.
At the highest aggregation level, which typically corresponds to the smart building scenario, complex sets of sensors, equipment, and energy resources (which may be independent or aggregated by local energy controllers) are supervised by a BEMS. In this case each BEMS (i.e., each smart building) is responsible for computing the forecast or feasible power profiles for each supervised entity, and for collecting the class of net power profiles computed by supervised energy controllers. The set of all of the computed power profiles are then aggregated as a new set of net power profiles, and forwarded to the supervisory EMS, by following the same monitoring and control process described for the local energy controller scenario.
The main advantages of distributed control architectures can be summarized as follows:
  • high scalability and flexibility: the use of decentralized intelligence doesn’t require the complete implementation of the monitoring and control functions of all of the supervised nodes in the supervisory layer. This allows the extension and modification of the supervised physical system (e.g., by adding new resources or modifying the existing configuration) without sensibly affecting the structure of the supervisory EMS;
  • reduced information throughput between the supervisory level and the system nodes: the implementation of distributed control functions at local nodes or aggregators allows the reduction of the computational complexity of the supervisory EMS. This also allows to reduce the rate of information exchange among the local nodes and the supervisory level, for both the monitoring and the control;
  • relaxed latency requirements for supervisory communication: the supervisory layer does not implement high-speed controls over the single nodes of the system, but provides predefined job schedules or power profile requests well in advance with respect to the time of actuation (up to three hours), and implements monitoring functions with refresh time interval of usually 15 min. Consequently, large communication latencies (on the order few minutes) for supervisory functions can be allowed.
Finally, it must be noted that the adoption of distributed control architectures does not usually require a performing communication infrastructure among the supervisory level and the single nodes of the control architecture, due to the small amount of information and to the large time intervals involved in the process (from 15 min for monitoring, to hours for scheduling).

2.2. The Role of IoT in Smart Environments

The literature review on the IoT area, such as well as its technological origin, is multidisciplinary. Many advances were necessary to make IoT, such as we know now, possible: from the hardware, to build ever smaller and smarter devices, passing through the communication technologies which allow wider covering distances and less energy consumption, the cloud computing, the storage of big amount of data, and the software industry.
IoT covers an extremely comprehensive area and can be applied in many sectors. From a pillar in Industry 4.0 to the way we take care of elderly people, IoT has been infiltrating in everyday life becoming an ubiquitous and pervading technology.
The use of IoT devices and applications in smart environments is nowadays a widespread practice. In smart homes, for instance, ubiquitous technologies are used to deal with the comfort, the healthcare, the safety, the security, and the energy conservation in dwellings [23]. Concerning energy savings, it must be noted that the monitoring of water and electricity consumption represents one of the main Key Performance Indicator (KPI) of energy efficiency in buildings [24], thus making this measurement step, essential. When it comes to smart buildings, additional functions are usually implemented, by including the monitoring of shared areas and facility equipment, such as elevators, toilets, patios, parking, etc. In the case of smart environments there are also concerns about the management of security, transportation, and other public services, thus calling for proper IoT architecture to support these kind of functionality. In particular, considering wider areas such as smart campuses, the employed IoT system must provide some LPWAN connectivity, which can deal with these demands [25,26,27,28,29,30]. Finally, in the context of smart cities, the goals can be more ambitious and reach more people, by aiming at sustainability, improving the life conditions of the population, and encouraging the creation of a creative economy [31,32,33].
As IoT is used for more and more purposes, several isolated implementations appear and, along with the lack of interoperability, the need for standardization also arises. A relevant effort was made by the academic community to propose reference architectures for IoT applications, and many solutions were proposed. A survey of these proposals can be found in [34]. Some of them clearly show, in terms of functional views, the features and services that should compose an IoT environment. Services such as device management, security, and communication can be seen as independent in terms of technology [35], thus giving designers many possibilities in terms of implementation of individual services.
Figure 2 shows the possible views of an IoT architecture. The simplest view is where every IoT application is composed by smart objects equipped with processing power and Internet connection, a middleware, and a user interface (see Figure 2 central view). All these components are part of the IoT architecture, although the middleware concentrates most of the functionalities.
A smart applications can be built in many ways. A recommended reference architecture is described in [36]. The leftmost view of Figure 2 represents the typical implementation of an IoT system, where smart devices are interconnected through wired and wireless networks. In this kind of network, devices are typically responsible for sensing and pre-processing the raw data before communicating with a gateway, which provides connection with a higher level network. The rightmost view of Figure 2 represents the IoT Service Platform and Enabler, which contains all the software applications which implement the main functionalities of the IoT platform, including the Application Programming Interfaces (APIs - visibles in the first view of Figure 2), such as well as additional features, such as security, availability, etc. The Application layer includes all the software applications which are specifically designed for the considered task, such as building automation or smart energy management.
Evaluating the current solutions proposed by the literature, it is clear that the IoT middleware plays an indispensable role. It is responsible for the most part of the IoT architecture functionalities, which include: device management, security, application logic, storage, rules logic, and, along with graphical user interface, the intermediation between users and devices. Besides, a cloud infrastructure serves as the IoT middleware environment, acting as a Platform as a Service (PaaS) paradigm and providing advantages as: horizontal scalability for processing power and storage, data backup, redundancy, and high availability.
An example of an IoT architecture than could be applied in complex smart environments, such as smart campuses, is the SaIoT (Smart Automation using Internet of Things) architecture [37,38,39], which was first developed for smart home and building applications. This architecture has been successfully in many measurement applications, such as water and electric energy consumption [40,41], by also including the computation of proper KPIs.

2.3. Low Power Wide Area Networks

The communication for IoT applied to smart environments can be carried out in several ways. Backend servers use traditional Internet infrastructures. Connectivity of IoT smart objects is mainly wireless: the most popular choices are technologies like Bluetooth, ZigBee, Z-Wave, and Wi-Fi, if the distances are up to 100 m. Beyond that range, there is the new field of the LPWAN technologies, where LoRaWAN and SigFox are the most widespread ones. Everything started considering that, in order to be effective, large coverage, network scalability, low-cost and low-power consumption are all fundamental requirements. Hence, LPWAN approach has been suggested as a viable answer to these requests. In particular, the LPWAN technologies trade off radio coverage, node density and power consumption with relatively long update rate. Generally speaking, LPWAN is an umbrella for covering those technologies that typically:
  • Operate in the sub-GHz unlicensed bands (avoiding the over-crowded and shorter range 2.4 GHz band); regional limitations may arise, which are usually accomplished by using “listen-before-talk” and duty-cycle based strategies;
  • Leverage on narrowband modulation, resulting in a limited raw throughput on one side, but providing very good receiver sensitivity (allowing a link budget on the order of 150 dB) on the other one;
  • Implement simple and low demanding protocol stacks complemented by simple communication infrastructure (thus minimizing both the power consumption and the cost); thus, end nodes are kept simple and the complexity is moved into the backend servers.
In particular, referring to the latter aspect, the network topology is a star (i.e., single-hop network), mimicking the approach typically pursued by mobile communications (in which mobile devices connect to a base station controlled by a base station manager). It has to highlight that mobile communications, despite partially overlap with LPWAN target scenarios, are an ideal complement and, especially when 5G systems will be available, could be used for implementing the backbone of a wireless multi-tier approach. In some papers, such possible integration has been discussed [42,43].
Considering the heterogeneous requirements of the Smart Campus application the most suitable LPWAN solution is LoRaWAN, whose main features are flexibility, scalability, wide diffusion, and module availability from many manufacturers. Moreover, the technical properties of LoRa (e.g., the virtual channels for implementing adaptive datarate) and the possibility to build proprietary infrastructure make LoRaWAN unique. On the other hand, SigFox is not suitable for smart campus since it operates on a third-party service provider, and it suffers from low datarate and fixed number of message per day. For sake of completeness, in Appendix A is reported an overview of LoRaWAN technology with a discussion of its features. An experimental validation of its suitability for the scope of this paper (in terms of coverage and latency) is also included.

3. The Proposed IoT Architecture for a Smart Campus

In this work, we propose an IoT architecture capable of covering a whole campus, in order to monitor and control energy resources. A smart campus environment brings new issues which require innovative solutions. In fact, the most critical seems to be the coverage area which will be extended through LPWAN technology. In particular, such as stated in Section 2.3, LoRaWAN is used in this work. Aside from the covering range extension, other features are also desired. They are:
  • Representation in the system of the physical locations of a campus as departments, blocks, classrooms, etc.;
  • Access control to device management and data per location;
  • Different levels of users: system administrator, local administrator, intern user per location, public user, etc.;
These last features have been implemented in the proposed solution, but they are not the focus of this paper. Instead, the description is concentrated on the covering range extension.
The proposed architecture provides multi protocol communication capabilities, such as described in the following. The devices communicate with the middleware based on a set of parameters, (including: the frequency of sensor data sending, the information model, the data encryption, how they manage the network connection state, how they manage device memory and the data management reporting, how they compute performance indices). The functions that are called (in the device) by the middleware to perform an action can also be defined as a parameter. The middleware provides services for the devices and users, besides the logic and rules of the application. Among the services provided for the sensors are: authentication, authorization, date and time synchronization, measurements storage, data management storage, etc. The user services include: visualization of the facility state, which reflects the state of the devices in real-time in a pleasant and organized way, report generator, where measurement data can be plotted in interactive charts to be better analyzed, device management, acting interface where they can turn lights on and off, open and close gates, valves, etc., besides the basic ones authentication and authorization. The middleware is also responsible for interoperability and integration of multi-protocol devices and to serve the API for the applications and user interfaces.
The schematic representation of the proposed IoT architecture is shown in Figure 3.

Integration with LoRaWAN

The integration of LoRaWAN with the proposed IoT architecture was implemented by using an open and easy-to-use solution: the LoRa Server project [44].
The LoRa Server project implements all the LoRaWAN stack and the set up can be done through a WEB interface. It has to be highlighted that within the LoRa Server Projects, the different LoRaWAN network components may have specific names which are different from the names used by the LoRaWAN standard. In particular, the LoRaWAN Network Server is called LoRa Server, the LoRaWAN Application Server is called LoRa App Server. The LoRa Server project has many possibilities for integration: via MQTT protocol; using cloud platforms (Google, AWS, Azure); by means of HTTP APIs; with direct access to databases, etc. In our case, we chose integration by means of HTTP API (i.e., the Lora App Server will make HTTP POST requests to the configured endpoints each time one events appear in the LoRaWAN network). The IoT architecture integrated with the LoRaWAN stack of the Lora Server project is shown in Figure 4.
The LoRaWAN integration follows the generic integration rules of the IoT system and can also be replicated for different communication technology, in a natural way for the final user.
The LoRaWAN mote can be considered the origin of the measurement. The measurement is then sent, wirelessly, to the LoRa gateway, which is the entry point to the LoRa Server software architecture. Finally, via HTTP integration, information is forwarded the IoT middleware part, where is processed and stored for later analysis.

4. The Proposed Use Case: Data Model and Scalability Analysis

As stated in the introduction, to the best of the authors’ knowledge, the detailed definition of a use–case, and of the related data model, is missing in the literature. For this reason, the definition of all the information involved in the communication process and the required data throughput in a smart campus scenario is discussed.

4.1. The Smart Campus Use Case

In this subsection, the smart campus use case is detailed according to distributed control architecture described in Section 2.1. From the point of view of the communication process, three different scenarios can be identified, for both the monitoring and the supervisory control functions: (i) the supervision of independent sensors, generators, and equipment, (ii) the coordination of local energy controllers, and (iii) the coordination of BEMS. In the proposed use case, only the scenario concerning independent sensors, generators, and equipment (including the related distributed controllers) will be considered, such as it represents the typical implementation of a LPWAN infrastructure integrating dispersed resources under the supervisory control of BEMSs or EMSs.
Different types of measuring instruments can be implemented in smart campus environments: from water and electrical power meters, to environmental sensors (e.g., for the measurement of room and ambient temperatures, volatile compound concentrations, solar irradiance, etc.), presence sensing devices, people counters, and many others. Concerning the amount of transferred information, electrical power meters are by far the most complex devices, by involving the measurement of several quantities, from energy flows, to power quality measurements. The reference set of information provided by such devices is reported in Table 1, by considering the typical set of measurements provided by a smart meter with a measuring full scale of 200 kVA.
As detailed in Table 1, the maximum size of each set of information transferred by electrical power meters to the supervisory EMS or BEMS is equal to 37 B, and the related application level data throughput is on the order of 0.041 B/s, by assuming a monitoring time interval of 15 min. On the opposite, when simple sensors are considered (e.g., sensors involving the measurement of a single quantity), the monitored set of information can be noticeably reduced. In this case, such as reported in Table 2, if we assume that a 16 bit value is adequate to represent any single measurement, the maximum size of each set of information is equal to 9 B, and the related data throughput is on the order of 0.01 B/s.
Concerning the transmission of information from the supervisory entity to independent sensors, the time information (synchronization) can be optionally requested by each sensor every 3 h (i.e., every twelve uplink messages), by using a confirmed LoRaWAN message. In this case a 8 B synchronization message (including the identification code of the sensor and the time reference) is sent by the EMS or the BEMS every 3 h, corresponding to a data throughput of about 0.00046 B/s.
When it comes to independent generators (i.e., power generators directly supervised by the smart campus EMS or by a single BEMS), the set of transferred information usually include the monitoring of energy flows, power quality measurements, such as well as specific operating parameters, and alarms. In Table 3, the reference set of information provided by power generators is reported, by considering the case of a photovoltaic (PV) inverter, which is one of the most diffused power assets in distributed generation scenarios. In this case, the nominal power of the generator was assumed to be on the order of 200 kVA. As detailed in Table 3, the maximum size of each set of information transferred by power generators to the supervisory entity is on the order of 30 B every 15 min, leading to an expected data throughput of about 0.033 B/s.
Concerning the transmission of information from the supervisory entity to independent generators, a set of control instructions is sent every 3 h, by using a confirmed LoRaWAN message (with the side benefit of not influencing the radio duty cycle of the gateway). The set of transferred information, such as detailed in Table 4, includes the identification code of the device, the time reference signal (for synchronization purposes), an active power profile representing the power limitation request to the specific generator (with a time resolution of 15 min), and the initial timestamp of the job schedule. In this case a 36 B message is sent to each supervised generator by the EMS or the BEMS every 3 h, corresponding to a data throughput of about 0.003 B/s.
In Table 5 the reference set of information provided by an independent equipment is reported, by considering the case of a HVAC system. In this case, such assuming that the monitored HVAC system is composed by a single device (e.g., a heat pump) with a nominal power consumption of 200 kVA, the maximum size of each set of information transferred by the system is on the order of 28 B every 15 min, leading to an expected data throughput of about 0.031 B/s.
Finally, concerning the transmission of information from supervisory entities to independent equipment, a more generalized scenario can be considered, i.e., by considering the provisioning of job schedules to single controllers, such as smart thermostats, smart plugs, or other simple equipment controllers. From the communication point of view, those devices can behave both as single sensors and as controllers. Acting as sensors, they communicate the state of the related controlled parameter (e.g., the room temperature) every 15 min, according to the data model described in Table 2. Acting as controllers, they receive a set of control instructions (e.g., room temperature set-points) every 3 h, by using a confirmed LoRaWAN message. As detailed in Table 6, the set of control instructions includes: the identification code of the device, the time reference signal (for synchronization purposes), a set-point profile (with a time resolution of 15 min), and the initial timestamp of the job schedule. Assuming that a 16 bit register is adequate for representing any possible set-point value, a 36 B message is sent to each smart controller every 3 h, with a corresponding data throughput of about 0.003 B/s.

4.2. Application Example

In this subsection an example of the application of the proposed LoRaWAN architecture for the monitoring of distributed energy resources in a real smart campus scenario is presented. The proposed communication architecture has been implemented for the monitoring of the operation and efficiency of a photovoltaic system installed in the engineering campus of the University of Brescia, Italy, such as part of the experimental activities of eLUX laboratory (https://elux.unibs.it/). The eLUX laboratory is a living lab for research, training, and services on smart-grids, smart-living and electric vehicles within the Engineering Campus of the University of Brescia. Further details on the assets and experiments of the laboratory can be found in [45].
As shown in the map depicted in Figure 5, the engineering campus of the University of Brescia has two points of common coupling with the distribution grid. The area highlighted in red in the map is fed by a Medium Voltage (MV) line of distribution network, while the area highlighted in blue is fed by a Low Voltage (LV) line. As shown in the map, the campus is equipped with four photovoltaic (PV) power plants (with a nominal power ranging from 10 to 111 kWp each) and two electrical storage systems (EESs).
The monitoring of the working parameters of all the installed equipment, such as well of additional field sensors (such as solar irradiance meters) is crucial for the performance analysis and maintenance of such energy assets. In particular, the monitoring of single components may be not sufficient for monitoring the proper operation of equipment, and the combined analysis of different parameters may be required. This is the case, for instance, of the analysis of the operation of PV inverters, where the combined monitoring of the working parameters of the inverter and of the solar irradiance on the PV strings connected to the inverter are essential to properly interpret the correct behavior of the equipment. The power output of the inverter, in fact, strictly depends on the power input provided by the PV strings, which is determined by the amount of solar irradiance collected by the PV modules forming the strings. By using these data, the efficiency of the PV inverter can be determined by computing the ratio between the power input and output, respectively. Conversely, potential malfunctioning of PV modules can be detected by computing the overall efficiency of the PV strings, i.e., by computing the ratio between the power input at the inverter and the total solar radiation on the PV strings (which is equal to the amount of measured solar irradiance multiplied by the total surface of the array of strings). Other relevant information on the health of the system and equipment can be also derived by the analysis of the Maximum Power Point (MPP) voltage inputs, compared with the amount of measured solar irradiance.
The supervisory monitoring of the PV inverters installed on 64 kW PV systems of the engineering campus of the University of Brescia is here proposed as example of the application of the proposed LoRaWAN architecture. The PV system is installed on the main building located on the north-east area of the campus, and connected to the LV public distribution grid. The PV array of the system is formed by 279 modules (model Trina Solar, TSM-230PC05), subdivided in 18 PV strings. The PV strings of the system are installed on three different pitches of the four stories building, with 91 modules facing South, 68 modules facing West, and 120 modules facing East. Three different solar irradiance sensors (model Si-RS485TC-T) are installed on each pitch. The PV strings are connected to six PV inverters (model ABB Power-One Aurora PVI-12.5-OUTD-FS-IT), which form the power conversion stage of the PV system. Each inverter is equipped with two separated Maximum Power Point Trackers (MPPTs), each connected to a single string and to a parallel of strings, respectively, to balance PV array input of the power conversion stage. While the solar irradiance sensors are installed on the roof of the building, the PV inverters are installed in the electrical equipment room located in the basement of the building. It is worth to note that in both the mentioned locations (i.e., the roof and the basement) the WiFi infrastructure implemented inside the building facilities is not available.
To allow the communication between the installed equipment and the main infrastructure of the building by using the proposed LoRaWAN architecture, the following experimental setup was deployed. Each of the solar irradiance sensors installed on the roof of the building was connected to a Raspberry Pi 3 device by means of a RS485 bus, and the data acquired by implementing the Modbus RTU protocol. Similarly, each of the PV inverter, communicating by using the proprietary Aurora protocol, was connected to an intelligent device (ABB PVI-RS485-MODBUS Converter), responsible for the conversion between the proprietary protocol and the Modbus RTU protocol. The latter was then connected to a Raspberry Pi 3 by means of a RS485 bus, and the data acquired by implementing the Modbus RTU protocol. Finally, each of the installed Raspberry Pi 3 was interconnected with a RN2483 LoRaWAN module. Examples of data collected by using the described LoRaWAN architecture are reported in Figure 6.

4.3. Scalability Analysis

Some simple analyses can be carried out to estimate the scalability of the proposed LPWAN infrastructure, by computing the maximum value of devices that can be managed by a single LoRaWAN base station. Referring to the data exchange procedure described above, from 9 B to 37 B messages are transmitted by field devices to supervisory entities every 15 min. Similarly, during downlink transmissions, 8 B to 36 B messages are exchanged every 3 h. If the additional 13 B required by the LoRaWAN headers and trailers are taken into account, the maximum uplink message is 50 B long, whereas the maximum downlink message is 49 B long. Alternatively, if we consider a more realistic scenario with a mixed set of simple sensors and complex devices, the average uplink message is 39 B long, and the average downlink message is 35 B long. Finally, if we consider the sum of the maximum uplink and downlink messages, including the LoRaWAN headers and trailers, about 649 B are exchanged every 3 h, leading to a maximum data throughput of 0.06 B/s, which means that the duty-cycle limitation of LoRaWAN is always satisfied.
In the following, the theoretical capacity of a single LoRaWAN base station is computed for the two presented scenarios, i.e., by considering that each installed device operates with the maximum expected payload (both at uplink and downlink), and by considering a mixed set of simple sensors and complex devices, each of them operating with the expected average uplink and downlink payload. In both the cases, the theoretical capacity of a single LoRaWAN base station is computed by assuming that every 3 h each cell must be able to manage up to twelve uplink messages with a length from 39 B to 50 B each (corresponding to the two considered scenarios), and one downlink message (with a length from 35 B to 49 B), per each served node, including the LoRaWAN headers and trailers. In this study, three different channels have been taken into account by varying the Spreading Factor (SF) from 7 to 12. The computed capacity of each LoRa base station is reported in Table 7 and Table 8, for the worst-case scenario (i.e., corresponding to the maximum expected payload) and for a realistic scenario (i.e., corresponding to the average expected payload), respectively.
Under perfect synchronization, the number of motes is given by N = T / T OA , where T is the considered refresh period (i.e., 3 h), and T OA is sum of the message over-the-air time duration per each node over T. If we consider that the actual throughput of ALOHA access is about 18% of the synchronized scenario [46], the maximum number of devices that can be managed by a single LoRaWAN base station is on the order of 3295 and 3919 devices per channel, for the worst-case and the realistic scenarios, respectively, which correspond to about 9885 and 11,757 devices per cell, when the three compulsory channels are adopted.

5. Conclusions

In this paper, we investigated the monitoring and supervisory control of distributed energy resources in smart campus environments. In particular, a detailed description of the addressed use case was presented, by proposing a comprehensive data model describing all the main functions provided by a reference control architecture. The heterogeneous requirements of communication infrastructure (e.g., indoor/outdoor coverage of large areas) are solved leveraging on LPWAN solutions. In particular, the use of LoRaWAN is here proposed due to its superiority with respect to other technologies, such as demonstrated by the experimental validation in terms of coverage and latency (resulting in a minimum single LoRaWAN cell coverage range of 250 m, and a communication latency of about 400 ms). A detailed analysis demonstrated that the proposed data model, tailored on LoRaWAN characteristics, permits to address and manage more than 10,000 smart nodes when a mixed set of simple sensors and complex devices (with a monitoring time interval of 15 min and a supervisory control interval of 3 h) are considered. Last, the advantages of the proposed solution for the supervision and management of dispersed photovoltaic and electrical energy storage systems in a smart campus are highlighted in a real-world scenario.

Author Contributions

Conceptualization, M.P., D.R.C.S. and P.F.; methodology, M.P.; software, D.R.C.S. and E.S.; validation, P.F., D.R.C.S. and M.P.; formal analysis, I.S.; investigation, M.P. and D.R.C.S.; resources, E.S.; data curation, M.P.; writing—original draft preparation, M.P. and D.R.C.S.; writing—review and editing, P.F., I.S. and E.S.; visualization, M.P.; supervision, P.F.; project administration, P.F.; funding acquisition, I.S. All authors have read and agreed to the published version of the manuscript.

Funding

This research received no external funding.

Acknowledgments

The authors would like to thank P. Palazzoli (A2A Smartcity) for the support given during experimental tests.

Conflicts of Interest

The authors declare no conflict of interest.

Appendix A. The LoRaWAN Communication Solutions

The aim of this appendix is to provide an overview of the LoRaWAN solution. Currently, LoRaWAN is recognized as the most diffused and well-accepted example of LPWAN radio technology in both the consumer and the academic worlds.
Differently from other LPWANs, LoRaWAN is an open standard, supported by an alliance in charge of drafting standards, with many manufacturers offering development solutions. Not surprisingly, very different application scenarios have been addressed in the market and in the literature, including precision agriculture [47,48], electric vehicles management [49,50], industry [51,52], buildings [53,54], and finally, smart campus [55,56].

Appendix A.1. LoRa and LoRaWAN Solutions

LoRaWAN nodes are based on a proprietary physical layer (the LoRa radio), developed and patented by Semtech. LoRa is an example of Chirp Spread Spectrum (CSS) modulation in which a single chirp frequency trajectory codes a symbol made of S F (the spreading factor) bits. If the chirp bandwidth is B W , the chirp duration is T C = 2 S F / B W . As a consequence, different S F values implement virtual channels, due to the quasi-orthogonal nature of the different chirps, thus partially overcoming bandwidth limits. In particular, B W [ 125 , 250 ] k H z and S F [ 7 12 ] in Europe, where the nodes operate in the 868 MHz band and must operate in duty-cycle regime. The possible data rates ranges from about 300 bps to 11 kbps, with a maximum allowed message length from 51 byte (at S F = 12 ) to 242 byte (at S F = 7 ). Forward Error Correction mechanism is employed for enhancing noise and interference immunity, with coding rates, C R , ranging from C R = 4 / 5 to C R = 4 / 8 .
The LoRaWAN specifications describe the data link layer, with a medium access strategy as simple as possible, typically based on pure ALOHA or clear channel assessment for limiting collisions in dense environment. The other protocol layers are not existing/defined and depend on the actual application. In particular, such as explained in the following, LoRaWAN is intended for providing a wireless “last-mile” connectivity to a large number of sensors in the field with a long refresh rate. For instance, if updates once every one minute are needed, thousands nodes are possible; on the contrary, if an update per day is tolerated, millions of nodes can be managed.
From the architectural point of view, two tiers exist in any LoRaWAN network; the first includes the wireless links with the end devices, while the second is the backend in charge of node management and furnishing services to end-users. In few words, a LoRaWAN infrastructure is designed to offer an independent transport service from the data source to the data destination, possible decoupling the owners of the different parts (data source, infrastructure, data destination) and thus allowing innovative service and business.
Uplinks originate from nodes and are collected by one or more Gateways (also known as concentrators or base stations) that forwards end-device messages to the backend; downlinks follow the opposite path. Message content is opaque for these Gateways, that run a “packet forwarder” software tunneling the incoming payload into an implementation-specific transport protocol, typically User Datagram Protocol (UDP), Transmission Control Protocol (TCP), or a message oriented middleware).
The LoRaWAN specifications define a network reference model including a set of (logical) servers (two or three depending on the version compliance): the Network Server (NS); the Application Server (AS) and the Join Server (JS), such as shown in Figure A1. The NS forwards uplinks to the intended AS and queues downlinks from the different ASs; if present, the JS manages the affiliation of new nodes. The NS is the intelligent part of the wireless network and can modify the node behavior (e.g., forcing data rate adaptation strategy) by means of a set of commands defined in the specs. Roaming is optionally supported; indeed, NS functionalities are further split into the only “serving NS” (sNS), managing the End-Device; the “home NS” (hNS) exchanging information with the AS; several additional “forwarding NS” (fNS, each one connected to other Gateways). If the sNS remains the same, roaming is said to be “passive”; on the contrary handover roaming is enabled. Regarding security aspects, the LoRaWAN protocol already provides mechanisms for mutual authentication, integrity protection and confidentiality. All the traffic is protected by using Network and Application session keys (which are managed by the JS); the former is used for computing a Message Integrity Code, the latter for end-to-end ciphering. Keys are managed by a dedicated server, which guarantees the segregation of NSs data from ASs data.
Interesting to note, only interfaces among NSs and JS-NS are defined and based on JavaScript Object Notation (JSON) objects exchanged via Hypertext Transfer Protocol (HTTP) protocol; all the other interfaces are based on proprietary solutions. In any case, the message payload is encrypted on a session base. Enciphering keys of end devices can be provisioned in the device before the deployment or provided over the air; on the contrary, backend security is left out to the implementer.
Figure A1. Architecture of a LoRaWAN network.
Figure A1. Architecture of a LoRaWAN network.
Applsci 10 00320 g0a1

Appendix A.2. Understanding LoRaWAN Limitations

The aim of this section is to briefly resume compromises and limitations resulting from the adoption of LoRaWAN (and alike) communication solutions. In few words, everything is related to the exchange of performance with low-power, low-cost and long-range requirements [57].
For instance, the long-range is obtained increasing the sensitivity of the radio, which in turn is permitted by low bandwidth. As a consequence, the bitrate is poor (down to a fraction of kbps for higher SF values, with a maximum user payload as low as 51 bytes). Consequently, message length can be in the order of several seconds, thus suffering from possibly high collision rate with other interfering messages in dense environment with frequent updates. On the other hand, the low-cost needs for simplified protocol, which permits the use of resource constrained microprocessors. For this reason, simple but inefficient ALOHA medium access strategy is chosen, instead of scheduled transmissions, which require some kind of synchronization.
Other limitations arise from the operation in sub-GHz unlicensed bands, where few channels are permitted, despite the aforementioned reduced bandwidth. Even if transmission of overlapping frames modulated using different SF typically results in the correct reception of all of them, such virtual channels are only quasi-orthogonal and implementing SF-multiplexing could be not so effective. Additionally, duty-cycle is bounded due to regional regulations; for example, when used in Europe in the EU 868 ISM band, the typical duty-cycle is 1 percent, therefore resulting in a maximum over-the-air time of 36 s/h in each sub-band for each device.
Regarding the protocol stack, it has to be highlighted that LoRaWAN specifications only define a transport mechanism from end-devices to users. Nothing is said about the actual application level; profiles, which pave the way to interoperability, are not defined. Indeed, users are free to overlay LoRaWAN communications with their own protocol, that has pros and cons. Referring to Figure 2, LoRaWAN is limited to the first four layers and only partially provides some services of the fifth one. Accordingly, it is the user’s responsibility to define and provide both application data and metadata.
Regarding fault tolerance, a LoRaWAN message sent by a node can be received by multiple Gateways, thus ensuring some form of redundancy at the link level. Successively, the NS intrinsically performs a deduplication operation in order to reject multiple copies. On the other hand, redundancy of the backend is out of the LoRaWAN scope, but can be implemented if needed.

Appendix A.3. LoRaWAN Implementations

Currently there are several different LoRaWAN solutions available; some of them are based on private infrastructure connecting proprietary nodes for specific applications [58,59,60], others, are based on public infrastructure offering free access for non-profit usage (despite some constraints in terms of available bandwidth exist) [61,62]. Additionally, some open-source implementations of the backend are available [63]. Notably, the LoRa Server [44] is a complete, ready-to-use and particularly easy to setup solution that includes both a web-based and a Representational State Transfer (REST) APIs for integration with third party applications.

Appendix A.4. Experimental Validation of LoRaWAN Solution

The experimental validation of the choice of LoRaWAN for implementing the proposed IoT architecture has been done in a real smart campus environment. It was carried out by measuring the coverage and latency of dispersed devices in the main campus of the Federal University of Rio Grande do Norte, Brazil (https://ufrn.br/institucional/localizacao).
It is worth noting that the adoption of a home automation into a Smart Campus infrastructure architecture is not only limited to the adoption of LoRaWAN. The management functionalities to support location, authentication and authorization have been also implemented before the experimental characterization took place, but they are not presented here because do not have impact on the presented results.
The experiment scenario consists of a LoRaWAN gateway, installed indoor at the Industrial Informatics Laboratory, acting as a packet forwarder and redirecting the received packets to a LoRaWAN backend, installed in a computer in the lab. A LoRaWAN mote, acting as a sensor, was connected to a supervision laptop and configured as a Class A device. Currently, no other LoRaWAN networks have been deployed in the campus. Figure A2 shows the experimental setup.
The LoRaWAN gateway is a Sentrius RG1XX device with the following characteristics: two antennas dual band Wi-Fi (2.4 GHz and 5 GHz), one LoRa antenna, and one Ethernet input (RJ45). The LoRa Gateway software is executed by a Atmel a5 core at 536 MHz with Linux kernel v4.x. It can interface itself with many LoRaWAN backend implementations: Semtech, LoRaIO, The Things Network (TTN), Stream, etc. The LoRaWAN mote is realized using a Microchip RN2903 module which has the following characteristics: Class A LoRaWAN implementation, support to the 915 Mhz ISM band, ASCII command interface and firmware update via UART, 14 GPIO pins (for general purpose input/output signals). The laptop and the LoRaWAN device were placed in a car which visited 20 points inside the campus to realize the following test procedure: a LoRaWAN message from the mote is sent by means of external commands issued by the supervision computer via USB interface; the gateway receives and forwards the packet to the registered LoRa server, which, in turn, propagates it through the LoRa stack as showed in Figure 4. As a consequence, no message overlapping can occur.
Each sent packet contains a payload of 50 bytes, a message size that it is compatible with the use case described in the previous section. The worst case condition from the sensitivity point of view was chosen: messages are sent using SF7 @ C/R = 4/5. The transmission power was set to +14 dBm. The timestamps of each sent package were recorded both on the supervision PC and on the LoRa Server for the analysis of message latency. The supervision PC and the LoRa Server have been synchronized by using NTP (Network Time Protocol).
To register the timestamps, the WhireShark software was installed on the supervison computer connected to the LoRaWAN mote and in the computer where the open LoRa Server stack was installed. Thus, the whole exchange of messages could be monitored. This procedure, used to measure the packages latency in a LoRaWAN infrastructure, was proposed in [64].
The experiment was started by choosing some geographical locations around the LoRaWAN gateway. The locations were chosen by increasing the distance between the gateway and the LoRaWAN mote. Figure A5 show the sending locations, identified by red balloons (i.e., transmission was successful) or black circles with a “x” inside (i.e., transmission was not successful), such as well as the gateway position, identified by a blue balloon.
Figure A2. Schematic representation of the experimental setup used for the LoRaWAN IoT architecture characterization.
Figure A2. Schematic representation of the experimental setup used for the LoRaWAN IoT architecture characterization.
Applsci 10 00320 g0a2
Figure A3. The Sentrius LoRa RG1XX gateway.
Figure A3. The Sentrius LoRa RG1XX gateway.
Applsci 10 00320 g0a3
Figure A4. The Microchip LoRaWAN mote based on RN2903.
Figure A4. The Microchip LoRaWAN mote based on RN2903.
Applsci 10 00320 g0a4
Figure A5. Map of measurement locations.
Figure A5. Map of measurement locations.
Applsci 10 00320 g0a5
The numbers above each red balloon indicate the order which the locations were visited. The light blue area indicates the covering range which the packets sent by the LoRaWAN mote reached the gateway. For each chosen location, the test procedure described above was repeated fifty times, recording the timestamps at both ends of the LoRaWAN link. In addition to its timestamp, each packet has its signal-to-noise ratio (SNR) and its received signal strength indicator (RSSI) recorded as provided by the LoRaWAN. By analyzing the records it is possible to determine the latency, SNR and RSSI according to device location. The results of the experimental validation are shown in Table A1 and Table A2.
The real operating distance is up to 250 m from the gateway when the campus scenario is considered. This distance is compatible with the usual LoRaWAN ranges when operating with SF7. The covered area is not symmetrical, a typical situation when real deployment scenarios are considered. The presence of tall buildings and complex terrain will reflect in the necessity to install more gateways to cover the entire campus area. The expected latency for the communication is shown in Table A2. The maximum latency is always under 400 ms with a very reduced jitter (defined as maximum minus minimum) of 20 ms. Such a latency is uniform across the campus. The low value of the latency is fully compatible with the Smart Campus application described in the use case, confirming the suitability of LoRaWAN for the proposed architecture.
Table A1. Distance of the Mote from the Gateway, average RSSI and average SNR.
Table A1. Distance of the Mote from the Gateway, average RSSI and average SNR.
Position IDDistance (m)RSSI (dBm)SNR (dB)
147−94.47.2
285−87.49.5
373−110.21.8
4118−93.85.2
592−97.49.2
672−82.45.5
7149−108.8−1.5
8221−113.2−5.5
987−105.65
10163−104.61.2
11183−109−1.5
12147−108.6−1.5
13165−88.86.5
14230−1091.5
15265−112.4−3.8
16248−99.48.8
17187−106.82.5
18235−109.6−0.2
19255−111.8−1.2
20240−112−5
Table A2. Transmission latency from the mote to the IoT middleware.
Table A2. Transmission latency from the mote to the IoT middleware.
Position IDAver. (ms)Std. Dev. (ms)Min. (ms)Max. (ms)
1372.06362381
2369.16361381
3372.16362380
4372.06362381
5369.46361380
6370.26362380
7368.56361380
8373.15366380
9372.05362381
10372.16361381
11370.46362379
12368.86362380
13371.45362380
14372.06361380
15373.25362382
16373.25367381
17373.35363382
18370.66361380
19372.16362380
20370.26361380

References

  1. Ahmad, M.W.; Mourshed, M.; Mundow, D.; Sisinni, M.; Rezgui, Y. Building energy metering and environmental monitoring—A state-of-the-art review and directions for future research. Energy Build. 2016, 120, 85–102. [Google Scholar] [CrossRef] [Green Version]
  2. Chen, Y.; Xu, P.; Gu, J.; Schmidt, F.; Li, W. Measures to improve energy demand flexibility in buildings for demand response (DR): A review. Energy Build. 2018, 177, 125–139. [Google Scholar] [CrossRef]
  3. Jouhara, H.; Yang, J. Energy efficient HVAC systems. Energy Build. 2018, 179, 83–85. [Google Scholar] [CrossRef]
  4. Granderson, J.; Lin, G.; Blum, D.; Page, J.; Spears, M.; Piette, M.A. Integrating diagnostics and model-based optimization. Energy Build. 2019, 182, 187–195. [Google Scholar] [CrossRef] [Green Version]
  5. Salimi, S.; Hammad, A. Critical review and research roadmap of office building energy management based on occupancy monitoring. Energy Build. 2019, 182, 214–241. [Google Scholar] [CrossRef]
  6. AlFaris, F.; Juaidi, A.; Manzano-Agugliaro, F. Intelligent homes’ technologies to optimize the energy performance for the net zero energy home. Energy Build. 2017, 153, 262–274. [Google Scholar] [CrossRef]
  7. Zhou, B.; Li, W.; Chan, K.W.; Cao, Y.; Kuang, Y.; Liu, X.; Wang, X. Smart home energy management systems: Concept, configurations, and scheduling strategies. Renew. Sustain. Energy Rev. 2016, 61, 30–40. [Google Scholar] [CrossRef]
  8. Rinaldi, S.; Flammini, A.; Pasetti, M.; Tagliabue, L.C.; Ciribini, A.C.; Zanoni, S. Metrological Issues in the Integration of Heterogeneous IoT Devices for Energy Efficiency in Cognitive Buildings. In Proceedings of the IEEE International Instrumentation and Measurement Technology Conference (I2MTC), Houston, TX, USA, 14–17 May 2018. [Google Scholar] [CrossRef]
  9. Howell, S.; Rezgui, Y.; Hippolyte, J.L.; Jayan, B.; Li, H. Towards the next generation of smart grids: Semantic and holonic multi-agent management of distributed energy resources. Renew. Sustain. Energy Rev. 2017, 77, 193–214. [Google Scholar] [CrossRef]
  10. Dou, C.x.; Liu, B. Hierarchical management and control based on MAS for distribution grid via intelligent mode switching. Int. J. Electr. Power Energy Syst. 2014, 54, 352–366. [Google Scholar] [CrossRef]
  11. Coelho, V.N.; Weiss Cohen, M.; Coelho, I.M.; Liu, N.; Guimarães, F.G. Multi-agent systems applied for energy systems integration: State-of-the-art applications and trends in microgrids. Appl. Energy 2017, 187, 820–832. [Google Scholar] [CrossRef]
  12. Pasetti, M.; Rinaldi, S.; Manerba, D. A Virtual Power Plant Architecture for the Demand-Side Management of Smart Prosumers. Appl. Sci. 2018, 8, 432. [Google Scholar] [CrossRef] [Green Version]
  13. Bellagente, P.; Bonafini, F.; Crema, C.; Depari, A.; Ferrari, P.; Lenzi, G.; Pasetti, M.; Rinaldi, S.; Sisinni, E. Enhancing Access to Industrial IoT Measurements by Means of Location Based Services. IEEE Instrum. Meas. Mag. 2018, 21, 15–21. [Google Scholar] [CrossRef]
  14. Viot, H.; Sempey, A.; Mora, L.; Batsale, J.; Malvestio, J. Model predictive control of a thermally activated building system to improve energy management of an experimental building: Part I—Modeling and measurements. Energy Build. 2018, 172, 94–103. [Google Scholar] [CrossRef]
  15. Viot, H.; Sempey, A.; Mora, L.; Batsale, J.; Malvestio, J. Model predictive control of a thermally activated building system to improve energy management of an experimental building: Part II—Potential of predictive strategy. Energy Build. 2018, 172, 385–396. [Google Scholar] [CrossRef] [Green Version]
  16. Sala-Cardoso, E.; Delgado-Prieto, M.; Kampouropoulos, K.; Romeral, L. Activity-aware HVAC power demand forecasting. Energy Build. 2018, 170, 15–24. [Google Scholar] [CrossRef]
  17. Macarulla, M.; Casals, M.; Forcada, N.; Gangolells, M. Implementation of predictive control in a commercial building energy management system using neural networks. Energy Build. 2017, 151, 511–519. [Google Scholar] [CrossRef] [Green Version]
  18. Cetin, K.S.; Fathollahzadeh, M.H.; Kunwar, N.; Do, H.; Tabares-Velasco, P.C. Development and validation of an HVAC on/off controller in EnergyPlus for energy simulation of residential and small commercial buildings. Energy Build. 2019, 183, 467–483. [Google Scholar] [CrossRef]
  19. Mary Reena, K.E.; Mathew, A.T.; Jacob, L. A flexible control strategy for energy and comfort aware HVAC in large buildings. Build. Environ. 2018, 145, 330–342. [Google Scholar] [CrossRef]
  20. Nilsson, A.; Lazarevic, D.; Brandt, N.; Kordas, O. Household responsiveness to residential demand response strategies: Results and policy implications from a Swedish field study. Energy Policy 2018, 122, 273–286. [Google Scholar] [CrossRef]
  21. Siano, P. Demand response and smart grids—A survey. Renew. Sustain. Energy Rev. 2014, 30, 461–478. [Google Scholar] [CrossRef]
  22. Barbato, A.; Bolchini, C.; Geronazzo, A.; Quintarelli, E.; Palamarciuc, A.; Pitì, A.; Rottondi, C.; Verticale, G. Energy optimization and management of demand response interactions in a smart campus. Energies 2016, 9, 398. [Google Scholar] [CrossRef] [Green Version]
  23. Mocrii, D.; Chen, Y.; Musilek, P. IoT-based smart homes: A review of system architecture, software, communications, privacy and security. Internet Things 2018, 1–2, 81–98. [Google Scholar] [CrossRef]
  24. Kim, D.W.; Kim, Y.M.; Lee, S.E. Development of an energy benchmarking database based on cost-effective energy performance indicators: Case study on public buildings in South Korea. Energy Build. 2019, 191, 104–116. [Google Scholar] [CrossRef]
  25. Nie, X. Constructing Smart Campus Based on the Cloud Computing Platform and the Internet of Things. In Proceedings of the 2nd International Conference on Computer Science and Electronics Engineering, Los Angeles, CA, USA, 1–2 July 2013; Atlantis Press: Paris, France, 2013. [Google Scholar] [CrossRef] [Green Version]
  26. Van Merode, D.; Tabunshchyk, G.; Patrakhalko, K.; Yuriy, G. Flexible technologies for smart campus. In Proceedings of the 13th International Conference on Remote Engineering and Virtual Instrumentation (REV), Madrid, Spain, 24–26 February 2016; pp. 64–68. [Google Scholar] [CrossRef]
  27. Hentschel, K.; Jacob, D.; Singer, J.; Chalmers, M. Supersensors: Raspberry Pi Devices for Smart Campus Infrastructure. In Proceedings of the 2016 IEEE 4th International Conference on Future Internet of Things and Cloud (FiCloud), Vienna, Austria, 22–24 August 2016; pp. 58–62. [Google Scholar] [CrossRef] [Green Version]
  28. Popoola, S.I.; Atayero, A.A.; Okanlawon, T.T.; Omopariola, B.I.; Takpor, O.A. Smart campus: Data on energy consumption in an ICT-driven. Data Brief 2018, 16, 780–793. [Google Scholar] [CrossRef]
  29. Webb, J.; Hume, D. Campus IoT collaboration and governance using the NIST cybersecurity framework. In Proceedings of the Living in the Internet of Things: Cybersecurity of the IoT, London, UK, 28–29 March 2018; pp. 1–7. [Google Scholar] [CrossRef]
  30. Havard, N.; McGrath, S.; Flanagan, C.; MacNamee, C. Smart Building Based on Internet of Things Technology. In Proceedings of the 2018 12th International Conference on Sensing Technology (ICST), Limerick, Ireland, 3–6 December 2018; pp. 278–281. [Google Scholar] [CrossRef]
  31. Arroub, A.; Zahi, B.; Sabir, E.; Sadik, M. A literature review on Smart Cities: Paradigms, opportunities and open problems. In Proceedings of the 2016 International Conference on Wireless Networks and Mobile Communications (WINCOM), Fez, Morocco, 26–29 October 2016; pp. 180–186. [Google Scholar] [CrossRef]
  32. Meijer, A.J.; Gil-Garcia, J.R.; Bolívar, M.P.R. Smart City Research: Contextual Conditions, Governance Models, and Public Value Assessment. Soc. Sci. Comput. Rev. 2016, 34, 647–656. [Google Scholar] [CrossRef]
  33. Achmad, K.A.; Nugroho, L.E.; Djunaedi, A.; Widyawan, W. Smart City Model: A Literature Review. In Proceedings of the 2018 10th International Conference on Information Technology and Electrical Engineering (ICITEE), Bali, Indonesia, 24–26 July 2018; pp. 488–493. [Google Scholar] [CrossRef]
  34. Ray, P. A survey on Internet of Things architectures. J. King Saud Univ.-Comput. Inform. Sci. 2018, 30, 291–319. [Google Scholar] [CrossRef] [Green Version]
  35. Martino, B.D.; Rak, M.; Ficco, M.; Esposito, A.; Maisto, S.; Nacchia, S. Internet of things reference architectures, security and interoperability: A survey. Internet Things 2018, 1-2, 99–112. [Google Scholar] [CrossRef]
  36. Borgia, E. The Internet of Things vision: Key features, applications and open issues. Comput. Commun. 2014, 54, 1–31. [Google Scholar] [CrossRef]
  37. Costa, J.; Araújo, D.; Silva, D.R.C.; Nogueira, M.B.; Rodrigues, M.C. Home Automation Architecture Based on IOT Technologies. In Proceedings of the 2018 Workshop on Metrology for Industry 4.0 and IoT, Brescia, Italy, 16–18 April 2018; pp. 63–67. [Google Scholar] [CrossRef]
  38. Silva, D.R.C.; Nogueira, M.B.; Rodrigues, M.C.; Costa, J.S.; Silveira, D.V.A.; Oliveira, G.M.B. A concrete architecture for smart solutions based on IoT technologies. IEEE Instrum. Meas. Mag. 2019, 22, 52–59. [Google Scholar] [CrossRef]
  39. Oliveira, G.M.B.; Costa, D.C.M.; Cavalcanti, R.J.B.V.M.; Oliveira, J.P.P.; Silva, D.R.C.; Nogueira, M.B.; Rodrigues, M.C. Comparison Between MQTT and WebSocket Protocols for IoT Applications Using ESP8266. In Proceedings of the 2018 Workshop on Metrology for Industry 4.0 and IoT, Brescia, Italy, 16–18 April 2018; pp. 236–241. [Google Scholar] [CrossRef]
  40. Tavares, S.A.; Cavalcanti, R.J.; Silva, D.R.; Nogueira, M.B.; Rodrigues, M.C. Telemetry for Domestic Water Consumption Based on IOT and Open Standards. In Proceedings of the 2018 Workshop on Metrology for Industry 4.0 and IoT, Brescia, Italy, 16–18 April 2018; pp. 1–6. [Google Scholar] [CrossRef]
  41. Neto, I.M.B.; Lopes, A.I.; Sousa Maria Alice De, M.; De Assis Brito, M.M.; Silva, D.R.C.; Nogueira, M.B.; Rodrigues, M.C. THDI Measurement System of Home Energy Signal Based on IoT. In Proceedings of the 2018 Workshop on Metrology for Industry 4.0 and IoT, Brescia, Italy, 16–18 April 2018; pp. 180–185. [Google Scholar] [CrossRef]
  42. Yasmin, R.; Petäjäjärvi, J.; Mikhaylov, K.; Pouttu, A. On the integration of LoRaWAN with the 5G test network. In Proceedings of the 2017 IEEE 28th Annual International Symposium on Personal, Indoor, and Mobile Radio Communications (PIMRC), Montreal, QC, Canada, 8–13 October 2017; pp. 1–6. [Google Scholar] [CrossRef] [Green Version]
  43. Navarro-Ortiz, J.; Sendra, S.; Ameigeiras, P.; Lopez-Soler, J.M. Integration of LoRaWAN and 4G/5G for the Industrial Internet of Things. IEEE Commun. Mag. 2018, 56, 60–67. [Google Scholar] [CrossRef]
  44. The LoRa Server Project. 2019. Available online: http://www.loraserver.io (accessed on 4 November 2019).
  45. Flammini, A.; Pasetti, M.; Rinaldi, S.; Bellagente, P.; Ciribini, A.L.C.; Tagliabue, L.C.; Zavanella, L.E.; Zanoni, S.; Oggioni, G.; Pedrazzi, G. A Living Lab and Testing Infrastructure for the Development of Innovative Smart Energy Solutions: the eLUX Laboratory of the University of Brescia. In Proceedings of the IEEE 110th AEIT International Conference, Bari, Italy, 3–5 October 2018. [Google Scholar] [CrossRef]
  46. Mikhaylov, K.; Petäjäjärvi, J.; Hänninen, T. Analysis of Capacity and Scalability of the LoRa Low Power Wide Area Network Technology. In Proceedings of the IEEE 22th European Wireless Conference on European Wireless, Oulu, Finland, 18–20 May 2016; pp. 119–124. [Google Scholar]
  47. Hisham Nik Ibrahim, N.; Rizan Ibrahim, A.; Mat, I.; Harun, I.A.N.; Witjaksono, G. LoRaWAN in Climate Monitoring in Advance Precision Agriculture System. In Proceedings of the 2018 International Conference on Intelligent and Advanced System (ICIAS), Kuala Lumpur, Malaysia, 13–14 August 2018; pp. 1–6. [Google Scholar] [CrossRef]
  48. Davcev, D.; Mitreski, K.; Trajkovic, S.; Nikolovski, V.; Koteli, N. IoT agriculture system based on LoRaWAN. In Proceedings of the 2018 14th IEEE International Workshop on Factory Communication Systems (WFCS), Imperia, Italy, 13–15 June 2018; pp. 1–4. [Google Scholar] [CrossRef]
  49. Santa, J.; Sanchez-Iborra, R.; Rodriguez-Rey, P.; Bernal-Escobedo, L.; Skarmeta, A.F. LPWAN-Based Vehicular Monitoring Platform with a Generic IP Network Interface. Sensors 2019, 19, 264. [Google Scholar] [CrossRef] [PubMed] [Green Version]
  50. Rinaldi, S.; Pasetti, M.; Sisinni, E.; Bonafini, F.; Ferrari, P.; Rizzi, M.; Flammini, A. On the Mobile Communication Requirements for the Demand-Side Management of Electric Vehicles. Energies 2018, 11, 1220. [Google Scholar] [CrossRef] [Green Version]
  51. Neumann, P.; Montavont, J.; Noël, T. Indoor deployment of low-power wide area networks (LPWAN): A LoRaWAN case study. In Proceedings of the 2016 IEEE 12th International Conference on Wireless and Mobile Computing, Networking and Communications (WiMob), New York, NY, USA, 17–19 October 2016; pp. 1–8. [Google Scholar] [CrossRef]
  52. Rizzi, M.; Depari, A.; Ferrari, P.; Flammini, A.; Rinaldi, S.; Sisinni, E. Synchronization Uncertainty Versus Power Efficiency in LoRaWAN Networks. IEEE Trans. Instrum. Meas. 2019, 68, 1101–1111. [Google Scholar] [CrossRef]
  53. Avotins, A.; Podgornovs, A.; Senfelds, A.; Vegeris, M. IoT solution approach for energy consumption reduction in buildings: part 2. Measurement setup and practical data analysis. In Proceedings of the 17th International Scientific Conference Engineering for Rural Development, Jelgava, Latvia, 23–25 May 2018. [Google Scholar] [CrossRef]
  54. Avotins, A.; Senfelds, A.; Nikitenko, A.; Podgornovs, A.; Zadeiks, K.; Dzenis, M. IoT Solution Approach for Energy Consumption Reduction in Buildings: Part 3. Mathematical Model of Building and Experimental Results. In Proceedings of the IEEE 59th International Scientific Conference on Power and Electrical Engineering of Riga Technical University (RTUCON), Riga, Latvia, 12–13 November 2018; pp. 1–8. [Google Scholar] [CrossRef]
  55. Ke, K.; Liang, Q.; Zeng, G.; Lin, J.; Lee, H. Demo Abstract: A LoRa Wireless Mesh Networking Module for Campus-Scale Monitoring. In Proceedings of the 2017 16th ACM/IEEE International Conference on Information Processing in Sensor Networks (IPSN), Pittsburgh, PA, USA, 18–21 April 2017; pp. 259–260. [Google Scholar]
  56. Yasmin, R.; Petäjäjärvi, J.; Mikhaylov, K.; Pouttu, A. Large and Dense LoRaWAN Deployment to Monitor Real Estate Conditions and Utilization Rate. In Proceedings of the 2018 IEEE 29th Annual International Symposium on Personal, Indoor and Mobile Radio Communications (PIMRC), Bologna, Italy, 9–12 September 2018; pp. 1–6. [Google Scholar] [CrossRef] [Green Version]
  57. Adelantado, F.; Vilajosana, X.; Tuset-Peiro, P.; Martinez, B.; Melia-Segui, J.; Watteyne, T. Understanding the Limits of LoRaWAN. IEEE Commun. Mag. 2017, 55, 34–40. [Google Scholar] [CrossRef] [Green Version]
  58. Yang, G.; Liang, H. A Smart Wireless Paging Sensor Network for Elderly Care Application Using LoRaWAN. IEEE Sens. J. 2018, 18, 9441–9448. [Google Scholar] [CrossRef]
  59. Lozano, A.; Caridad, J.; De Paz, J.F.; Villarrubia González, G.; Bajo, J. Smart Waste Collection System with Low Consumption LoRaWAN Nodes and Route Optimization. Sensors 2018, 18, 1465. [Google Scholar] [CrossRef] [Green Version]
  60. Bebelaar, N.; Braggaar, R.C.; Kleijwegt, C.M.; Meulmeester, R.W.E.; Michailidou, G.; Salheb, N.; van der Spek, S.; Vaissier, N.; Verbree, E. Monitoring urban environmental phenomena through a wireless distributed sensor network. Smart Sustain. Built Environ. 2018, 7, 68–79. [Google Scholar] [CrossRef]
  61. The Things Network Official Web Site. 2019. Available online: https://www.thethingsnetwork.org/docs/network/architecture.html (accessed on 4 November 2019).
  62. Semtech Network Server. 2019. Available online: https://iot.semtech.com (accessed on 4 November 2019).
  63. Semtech Reference Implementation. 2019. Available online: https://semtech.my.salesforce.com/sfc/p/#E0000000JelG/a/E00000008tMV/uzTzH5NK6cIbW50_y3fS7p8DQ4etziSqzp.6PSgPmjw (accessed on 4 November 2019).
  64. Carvalho, D.F.; Ferrari, P.; Sisinni, E.; Depari, A.; Rinaldi, S.; Pasetti, M.; Silva, D. A test methodology for evaluating architectural delays of LoRaWAN implementations. Pervasive Mob. Comput. 2019, 56, 1–17. [Google Scholar] [CrossRef]
Figure 1. Distributed monitoring and control architecture in a smart campus.
Figure 1. Distributed monitoring and control architecture in a smart campus.
Applsci 10 00320 g001
Figure 2. Multiple views of the IoT architecture (The rightmost model is defined in [36]).
Figure 2. Multiple views of the IoT architecture (The rightmost model is defined in [36]).
Applsci 10 00320 g002
Figure 3. The proposed IoT architecture.
Figure 3. The proposed IoT architecture.
Applsci 10 00320 g003
Figure 4. The IoT architecture with LoRaWAN integration.
Figure 4. The IoT architecture with LoRaWAN integration.
Applsci 10 00320 g004
Figure 5. Map of the engineering campus of the University of Brescia. PV: Photovoltaic, POD: Point of Delivery, MV: Medium Voltage, LV: Low Voltage.
Figure 5. Map of the engineering campus of the University of Brescia. PV: Photovoltaic, POD: Point of Delivery, MV: Medium Voltage, LV: Low Voltage.
Applsci 10 00320 g005
Figure 6. Examples of data collected by using the described LoRaWAN architecture on 26 November 2019 between 7:00 and 17:00 UTC.
Figure 6. Examples of data collected by using the described LoRaWAN architecture on 26 November 2019 between 7:00 and 17:00 UTC.
Applsci 10 00320 g006
Table 1. List of information packed into each data sample transferred by a single low voltage smart power meter. Each information is computed as the average of all of the measured samples over the given monitoring time interval. For reactive power measurements, positive values represent inductive loads, while negative values represent capacitive loads. THD: Total Harmonic Distortion, RMS: Root Mean Square.
Table 1. List of information packed into each data sample transferred by a single low voltage smart power meter. Each information is computed as the average of all of the measured samples over the given monitoring time interval. For reactive power measurements, positive values represent inductive loads, while negative values represent capacitive loads. THD: Total Harmonic Distortion, RMS: Root Mean Square.
InformationRangeResolutionSize (B)
Identification code of the sensor--2
Timestamp of the set of information-1 s5
Three-phase voltage (RMS value) 0 ÷ 500 V < 0.01 V2
Three-phase current (RMS value) 0 ÷ 300 A < 0.01 A2
Three-phase active power 0 ÷ 200 kW0.01 W3
Three-phase reactive power - 200 ÷ 200 kvar0.02 var3
Phase 1 voltage (RMS value) 0 ÷ 250 V1 V1
Phase 1 current (RMS value) 0 ÷ 150 A < 0.01 A2
Phase 1 voltage THD 0 ÷ 100 % < 1 %1
Phase 1 current THD 0 ÷ 100 % < 1 %1
Phase 1 Power Factor (PF) 0 ÷ 1 < 0.01 1
Phase 2 voltage (RMS value) 0 ÷ 250 V1 V1
Phase 2 current (RMS value) 0 ÷ 150 A < 0.01 A2
Phase 2 voltage THD 0 ÷ 100 % < 1 %1
Phase 2 current THD 0 ÷ 100 % < 1 %1
Phase 2 Power Factor (PF) 0 ÷ 1 < 0.01 1
Phase 3 voltage (RMS value) 0 ÷ 250 V1 V1
Phase 3 current (RMS value) 0 ÷ 150 A < 0.01 A2
Phase 3 voltage THD 0 ÷ 100 % < 1 %1
Phase 3 current THD 0 ÷ 100 % < 1 %1
Phase 3 Power Factor (PF) 0 ÷ 1 < 0.01 1
Grid Frequency 0 ÷ 100 Hz < 0.01 Hz2
Table 2. List of information packed into each data sample transferred by a generic single sensor. Each information is computed as the average of all of the measured samples over the given monitoring time interval.
Table 2. List of information packed into each data sample transferred by a generic single sensor. Each information is computed as the average of all of the measured samples over the given monitoring time interval.
InformationRangeResolutionSize (B)
Identification code of the sensor--2
Timestamp of the set of information-1 s5
Single measurement--2
Table 3. List of information packed into each data sample transferred by a single photovoltaic inverter. Each information is computed as the average of all of the measured samples over the given monitoring time interval. For reactive power measurements, positive values represent inductive loads, while negative values represent capacitive loads. MPPT: Maximum Power Point Tracker.
Table 3. List of information packed into each data sample transferred by a single photovoltaic inverter. Each information is computed as the average of all of the measured samples over the given monitoring time interval. For reactive power measurements, positive values represent inductive loads, while negative values represent capacitive loads. MPPT: Maximum Power Point Tracker.
InformationRangeResolutionSize (B)
Identification code of the generator--2
Timestamp of the set of information-1 s5
Three-phase voltage (RMS value) 0 ÷ 500 V < 0.01 V2
Three-phase current (RMS value) 0 ÷ 300 A < 0.01 A2
Three-phase active power 0 ÷ 200 kW0.01 W3
Three-phase reactive power 200 ÷ 200 kvar0.02 var3
Three-phase Power Factor (PF) 0 ÷ 1 < 0.01 1
Grid Frequency 0 ÷ 100 Hz < 0.01 Hz2
MPPT 1 voltage 0 ÷ 1000 V0.015 V2
MPPT 1 current 0 ÷ 200 A < 0.01 A2
MPPT 2 voltage 0 ÷ 1000 V0.015 V2
MPPT 2 current 0 ÷ 200 A < 0.01 A2
Alarm Code--2
Table 4. List of information packed into each data sample transferred to a single photovoltaic inverter. Each power profile is defined as an active power limitation request, with a time horizon of 3 h, and a time resolution of 15 min.
Table 4. List of information packed into each data sample transferred to a single photovoltaic inverter. Each power profile is defined as an active power limitation request, with a time horizon of 3 h, and a time resolution of 15 min.
InformationRangeResolutionSize (B)
Identification code of the generator--2
Synchronization Timestamp-1 s5
Initial timestamp of the job schedule-1 s5
Requested power profile 0 ÷ 200 kW3 W24
Table 5. List of information packed into each data sample transferred by a HVAC system consisting of a single heat pump with a nominal power consumption of 200 kVA. Each information is computed as the average of all of the measured samples over the given monitoring time interval.
Table 5. List of information packed into each data sample transferred by a HVAC system consisting of a single heat pump with a nominal power consumption of 200 kVA. Each information is computed as the average of all of the measured samples over the given monitoring time interval.
InformationRangeResolutionSize (B)
Identification code of the equipment--2
Timestamp of the set of information-1 s5
Active power consumption 0 ÷ 200 kW0.01 W3
Chiller temperature 0 ÷ 100 °C < 0.01 °C2
Boiler temperature 0 ÷ 100 °C < 0.01 °C2
Cold circuit inlet temperature 0 ÷ 100 °C < 0.01 °C2
Cold circuit outlet temperature 0 ÷ 100 °C < 0.01 °C2
Warm circuit inlet temperature 0 ÷ 100 °C < 0.01 °C2
Warm circuit outlet temperature 0 ÷ 100 °C < 0.01 °C2
Cold circuit mass flow rate 0 ÷ 100 kg/s < 0.01 kg/s2
Warm circuit mass flow rate 0 ÷ 100 kg/s < 0.01 kg/s2
Alarm Code--2
Table 6. List of information packed into each data sample transferred to a single equipment controller. Each set-point profile is defined as list of set-point values, with a time horizon of 3 h, and a time resolution of 15 min.
Table 6. List of information packed into each data sample transferred to a single equipment controller. Each set-point profile is defined as list of set-point values, with a time horizon of 3 h, and a time resolution of 15 min.
InformationRangeResolutionSize (B)
Identification code of the device--2
Synchronization Timestamp-1 s5
Initial timestamp of the job schedule-1 s5
Setpoint profile--24
Table 7. Capacity of a single LoRaWAN base station (reported as number of allowed motes per channel) in the worst-case scenario, corresponding to twelve consecutive uplink messages of 50 B each, and one downlink message of 49 B, with CR = 4/5 and BW = 125 kHz. CR: Coding Rate, BW: Bandwitdh, T OA : Sum of the Time-on-Air per each node over the considered refresh period T.
Table 7. Capacity of a single LoRaWAN base station (reported as number of allowed motes per channel) in the worst-case scenario, corresponding to twelve consecutive uplink messages of 50 B each, and one downlink message of 49 B, with CR = 4/5 and BW = 125 kHz. CR: Coding Rate, BW: Bandwitdh, T OA : Sum of the Time-on-Air per each node over the considered refresh period T.
Spreading Factor T OA (ms)Cell Capacity per Channel *Cell Capacity per Channel **
7126385511539
822704758856
942532539457
1079731354243
1114,881725130
1227,63239070
* under perfect synchronization, ** pure ALOHA access.
Table 8. Capacity of a single LoRaWAN base station (reported as number of allowed motes per channel) in a realistic scenario, corresponding to twelve consecutive uplink messages of 39 B each, and one downlink message of 35 B, with CR = 4/5 and BW = 125 kHz. CR: Coding Rate, BW: Bandwitdh, T OA : Sum of the Time-on-Air per each node over the considered refresh period T.
Table 8. Capacity of a single LoRaWAN base station (reported as number of allowed motes per channel) in a realistic scenario, corresponding to twelve consecutive uplink messages of 39 B each, and one downlink message of 35 B, with CR = 4/5 and BW = 125 kHz. CR: Coding Rate, BW: Bandwitdh, T OA : Sum of the Time-on-Air per each node over the considered refresh period T.
Spreading Factor T OA (ms)Cell Capacity per Channel *Cell Capacity per Channel **
7105810,2061837
819835446980
934543126562
1063751693304
1112,669852153
1223,37246283
* under perfect synchronization, ** pure ALOHA access.

Share and Cite

MDPI and ACS Style

Pasetti, M.; Ferrari, P.; Silva, D.R.C.; Silva, I.; Sisinni, E. On the Use of LoRaWAN for the Monitoring and Control of Distributed Energy Resources in a Smart Campus. Appl. Sci. 2020, 10, 320. https://doi.org/10.3390/app10010320

AMA Style

Pasetti M, Ferrari P, Silva DRC, Silva I, Sisinni E. On the Use of LoRaWAN for the Monitoring and Control of Distributed Energy Resources in a Smart Campus. Applied Sciences. 2020; 10(1):320. https://doi.org/10.3390/app10010320

Chicago/Turabian Style

Pasetti, Marco, Paolo Ferrari, Diego Rodrigo Cabral Silva, Ivanovitch Silva, and Emiliano Sisinni. 2020. "On the Use of LoRaWAN for the Monitoring and Control of Distributed Energy Resources in a Smart Campus" Applied Sciences 10, no. 1: 320. https://doi.org/10.3390/app10010320

Note that from the first issue of 2016, this journal uses article numbers instead of page numbers. See further details here.

Article Metrics

Back to TopTop