Evaluation of the Use of Class B LoRaWAN for the Coordination of Distributed Interface Protection Systems in Smart Grids

: The adoption of the distributed generation paradigm is introducing several changes in the design and operation of modern distribution networks. Modern grid codes are becoming more and more complex, and the adoption of smart protection systems is becoming mandatory. However, the adoption of newer and smarter units is only half of the story. Proper communication networks must be provided as well, and the overall costs may become critical. In this work, the adoption of the Long-Range Wide Area Network (LoRaWAN) technology is suggested as a viable approach to implement the coordination of Interface Protection Systems. A proper communication architecture based on the LoRaWAN Class B technology was proposed and evaluated in order to assess its feasibility for the considered application. A scalability analysis was carried out, by computing the number of devices that can be handled by a single LoRaWAN Gateway (GW) and the maximum expected time of response between a triggering event and the arrival of the related coordination command. The results of the study showed that up to 312 devices can be managed by a single GW, by assuring a maximum response time of 22.95 s. A faster maximum response time of 6.2 s is also possible by reducing the number of managed devices to 12.


Introduction
The increasing penetration of Distributed Generation (DG) from Renewable Energy Resources (RESs) is heavily affecting the design and operation of modern power grids [1,2]. The growing diffusion of dispersed generators installed at end users' premises is calling for the adoption of advanced control and protection mechanisms, to comply with the increasing complexity of grid codes. New functions are being introduced, year over year, by national regulatory frameworks, thus often requiring the implementation of intelligent devices. New devices are required to implement advanced control capabilities over Distributed Energy Resources (DERs) and Energy Storage Systems (ESSs) [3,4], including the provisioning of active and reactive power limitations and of ancillary services, such as voltage and frequency control. At the same time, existing devices implementing the classical protection functions devoted to the safe operation of Distribution Networks (DNs) and of electrical equipment are also involved [5,6]. The application of the most recent protection functions defined by current regulatory frameworks [7,8] is indeed calling for advanced communication capabilities, thus posing an increasing interest on the development of smart protection devices and that, even though the use of the LoRaWAN technology was already proposed in the literature for the coordination of circuit breakers in MV distribution networks, its application for IPSs was never specifically investigated. In particular, in Ref. [16], the use of Class A LoRa devices was proposed to implement logic selectivity mechanisms in MV networks. However, this study focused only on the coordination of MV circuit breakers, without taking into consideration the specific requirements of IPSs in terms of data monitoring and coordinated control messages.
In particular, it must be stressed that knowing the performance of the communication infrastructure is only one side of the coin. In order to correctly evaluate the usability of the LoRaWAN technology in a specific field of application, it is first of all mandatory to define a proper use case, and only once user application details are known is it possible to verify if and how well they match the communication infrastructure characteristic. Currently, neither the first nor the second aspects have been discussed for the coordination of distributed IPSs.
Following the preliminary work presented in [17], this study aims at filling this gap by answering the following questions:  is the LoRaWAN technology able to handle the amount of data and the response time intervals required for the coordination of IPSs in smart and micro grids?  how many devices can be coordinated by a single LoRaWAN gateway?
To answer these questions, the monitoring and control functions of IPSs was first defined, by referring to the Italian regulatory framework on the matter. Based on these requirements, a proper communication architecture based on the LoRaWAN Class B technology was proposed, by also defining a specific data model structure, to allow the computation of the payload of the communication. Finally, a scalability analysis on the application of the proposed LoRaWAN architecture was proposed, by computing the number of devices that can be handled by a single LoRaWAN gateway and the maximum expected time of response between a triggering event and the arrival of the related coordination command. The analysis was carried out by computing the Timeon-Air duration of monitoring and supervisory control messages, by varying the main parameters of the communication, i.e., the ping period and the spreading factor.
For the sake of completeness, a real-world use case was also presented, to allow the reader to understand the critical aspects related to the coordination of IPSs in complex systems, and thus to better comprehend the benefits introduced by the proposed LoRaWAN solution. The use case introduced in this study is based on the configuration of the IPSs installed in the Engineering campus of the University of Brescia, Italy, which presents four independent LV DG units (three photovoltaic systems and one ESS) connected to a MV Point of Common Coupling (PCC) with the DN.
The structure of the paper is organized as follows. In Section 2, the main characteristics of IPSs are briefly presented, and their main protection functions and coordination requirements are introduced. Further details on the protection functions defined by the current Italian regulatory framework are reported in Appendix A. In Section 3, the configuration of the IPSs installed in the Engineering campus of the University of Brescia is described, to note the current limitations related to the coordination of IPSs installed in complex systems, and thus to highlight the benefits introduced by the proposed solution. The detailed description of the communication system implemented by the current IPS configuration is reported in Appendix B. Section 4 presents a brief introduction on the LoRaWAN technology, to allow the readers to better understand its use in the proposed application. In Section 5, a proper communication mechanism based on the LoRaWAN Class B technology is proposed for the coordination of dispersed IPSs, and the related data model structure is described in detail. In Section 6, the scalability and sensitivity analyses of the proposed solution are presented and discussed. Finally, in Section 7, the main findings of the study are summarized, and the conclusions are presented. For the sake of completeness, the list of the abbreviations and the nomenclature adopted in the manuscript have been reported in Abbreviations and Nomenclature.

Coordination Requirements of Interface Protection Systems
Interface Protection Systems are protection devices which are used to prevent the undesired operation in islanding mode of distributed generators installed in smart and micro-grids. IPSs are designed to detect the loss of connection with the DN and to disconnect the supervised generation units, in order to inhibit their operation in islanded mode. The loss of the main connection is usually detected as a violation of predefined voltage and frequency acceptable bands [10]. The safe implementation of anti-islanding protection functions represents a critical task in modern DNs, due to the relevant risks related to the unintentional islanding of DG units, even if operated for a very short time. The main effects include the feeding of DN lines during planned disconnections of the main grid (which expose grid operators to safety risks) and the risk of degradation of electrical equipment during automatic grid reconnections. The latter, in particular, may be caused by possible voltage drifts of the islanded portion of the electrical network with respect to that of the main grid [18].
The schematic diagram in Figure 1 represents the classic connection scheme of an IPS in its most simple configuration. The Interface Protection (IP) is the intelligent device that makes measurements of voltage and frequency values of the supervised DG unit. When an undesired islanding is detected, IP forces the disconnection of the unit from the main grid by opening the associated Interface Device (ID). The ID typically behaves as a normally opened (NO) circuit breaker driven by a "minimum voltage coil" with remote tripping contact. The couple formed by an IP and its related ID is one IPS. IPs and IDs may be combined into a single IED to create an IPS device. A single IP can drive more than one ID, depending on the specific system configuration. For what concerns the coordination of IPSs, it must be noted that, for systems equipped with several distinct generators (or, more generally, equipped with several distinct IPSs), a proper coordination mechanism among all of the installed IPSs must be provided to meet the requirements set by grid codes. In this case, when an anomaly is detected by an IPS, a coordination command must be provided to all the installed devices, causing the TRIP of all the IPSs installed in the system.
Finally, the capability of implementing remote TRIP signals from supervisory systems must also be taken into account. Depending on the specific system configuration, the installation of a remote TRIP system may be in fact required, by enabling the DSO to disconnect all the installed generators by means of remote signals. This must be applied in Italy, for instance, for systems with a total installed power greater than 100 kWp, connected to High Voltage (HV) or MV DNs, as defined by the regulation CEI 0-16, Annex M [19]. In this case, a remote signal is sent by the DSO to one entry point installed in the user's system (typically implemented by means of a GSM or GPRS receiver), which must be connected to all the user's IPSs, in order to ensure the disconnection of all the supervised GD or ESS units. In addition, a proper "protection opening failure" monitoring system must be provided for each installed ID. It is worth noting that the regulation allows the installation of only one entry point per each user, thus requiring the installation of a proper IPS coordination system.

A Real-World Use Case: The Engineering Campus of the University of Brescia
The Engineering campus of the University of Brescia is connected to a MV (15 kV) DN. The MV network of the campus has five MV/LV substations that, in turn, feed a complex system of LV lines. Figure 2 shows the simplified schematic diagram of the electrical network of the campus, by focusing on the connection of the DG units to the main MV feeder, and on the configuration of their IPSs. As shown by the schematic diagram of Figure 2, the campus has three Photovoltaic (PV) power plants (10 kWp, 13 kWp and 111 kWp) and one ESS (molten salt-Na-NiCl2) with a nominal capacity of 25.3 kWh, and a nominal power of 7 kWp. The PV systems are connected to different LV line of different MV/LV substation. The ESS is connected to the same LV line of the PV-3 system. More detailed information about the electrical equipment installed in the campus can be found in [20].
The DG units of the campus are equipped with an IPS, which is connected to the respective LV line. In detail, three independent IPSs are installed: IPS-1 and IPS-2 (each connected to a single ID) are the protection of PV-1 and PV-2, respectively; IPS-3 protects PV-3 and the ESS (by means of two dedicated IDs with OR configuration). According with the current Italian regulation, the three IPSs have been configured as uncoordinated IPSs, i.e., without implementing the "OR logic" configuration. The three IPSs implement the protection function 59N through the indirect mode, by means of a dedicated IP (IP 59N) placed at the MV substation of the campus. Finally, a GPS device connected to the PV-1 IPS implements the remote TRIP signal provided by the DSO. Further details on the configuration of the communication system implementing the 59N function and the remote TRIP signal from the DSO are provided in Appendix B.
As schematically represented in Figure 3, the main limitations of the IPS coordination system currently implemented in the campus can be summarized as follows: circuit. In this case, the installation costs (including digs, operation in MV substations, etc.) reached thousands of euros, i.e., an amount of money comparable to that of the components of the PV system;  Scarce scalability: in the case of the installation of a new PV section in the campus, all of the existing IPSs will require a much more complex coordination system, due to the need of the implementation of the "OR logic" configuration (currently not applied, thanks to the limited number of installed IPSs);  Low reliability and high maintenance costs: the use of a coordination system based on analog signals is less reliable and maintainable than a system based on digital signals. The current configuration, in fact, requires technical personnel to continuously monitor all the analog connections to guarantee the correct operation of the DG units;  Scarce flexibility: in the case of future (and most probable) modifications to the current regulatory framework, e.g., involving the coordination between protections, remote trip or power limitation commands, etc., the current solution would not allow updating actions, but it would require a complete system reconfiguration by making use of a dedicated digital communication network. According to the previous discussion, it is clear that the coordination of smart IPSs can take a lot of advantages from the adoption of a digital communication system. Wired solutions based on the widespread Ethernet (over copper or optical fiber links), which generally offer better performance, suffer from higher installation costs. The adoption of PLC is limited to IEDs of the same LV substation and does not satisfy needs for addressing IPSs sparse in complex MV/LV user's networks.
In this work, the adoption of the LoRaWAN technology is suggested as a viable wireless approach, permitting to lower the installation and maintenance costs. Indeed, the considered application does not require high data throughputs and can take advantage from the large area coverage in both indoor and outdoor scenarios.

The LoRaWAN Technology
Despite several different Low-power Wide Area Network (LPWAN) solutions having been proposed in the recent past, most of the already deployed applications leverage on the LoRaWAN technology. The radio link is implemented via a proprietary chirp spread spectrum modulation, developed by Semtech and named LoRa. On the contrary, protocols of the upper levels are managed by the LoRa Alliance, who managed the drafting of the LoRaWAN specifications. The aim of the specs is to describe the medium access strategy and the overall system architecture, including the functionalities of the backend. In particular, any LoRaWAN network can be split into two tiers. The first one is the wireless tier, providing a single-hop connectivity between end nodes and gateways (GWs). It has to be stressed that the very high sensitivity of the radio, complemented by the processing gain obtained by enlarging the symbol duration (set by a parameter called Spreading Factor-SF), allows for a large area coverage, minimizing the impact of the star only topology, chosen for the needs for efficiency and low power consumption. The role of the gateways is to tunnel radio messages (in the uplink or downlink directions, depending if they are transmitted or received by the end device) towards the backend, in which the Network Server (NS) takes care of the resource assignment, while the Application Server (AS) offers services for implementing the actual end user application. Regarding possible limitations, it has to remembered that LoRa radio operates in sub-GHz unlicensed bands and must cope with regional regulations in terms of duty-cycle and transmission power.
End devices are grouped into three classes, depending on how downlink is managed. The basic class, which includes a minimal set of functionalities, is the Class A; downlink must follow an eventbased uplink, thus permitting the end devices to decide when to start the transmission and possibly to spend most of the time in a low-power sleep mode. Synchronized downlink messages are permitted by Class B. Continuous listening, allowing for completely asynchronous downlink, is added in Class C. It is evident that typical IoT applications, targeted by LoRaWAN, match the Class A behavior well, as confirmed by the few Class B solutions actually deployed.
Time dissemination in Class B occurs via Beacon transmission, i.e., well-defined messages transmitted every Beacon period TB by GWs. If Beacons are lost for more than two hours, the node turns back into the Class A mode. The TB interval is discretized into 4096 ping slots lasting each one 30 ms (and TB = 128 s, thus including an additional guard time). Downlink messages are permitted on ping slot edges; an end device can be configured to listen at the ping slot N, so that it has to turn on the receiver after Ton from the Beacon reception, where Ton = 2.12 s + (offset+N·TP)·30 ms and TP is the ping period, representing the actual device wake up interval. In particular, TP = 4096/Nb, where Nb = 2 k , k = 0...7. A pseudo-random offset, changed every Beacon period, is added to reduce the risk of collisions and the overhearing; such an offset can range from zero to TP. As a consequence, the minimum ping period is TP,min = 960 ms, obtained with k = 7. Class B and Class C also introduce the concept of multicast messages, opposed to unicast. By the way, many devices can belong to a multicast group (identified by a single multicast address and provided with a multicast enciphering key). However, the actual mechanism permitting multicast communications is out of the specifications scope and depends on the actual LoRaWAN implementation.
The success of LoRaWAN is demonstrated by the huge literature available. In particular, some works already highlighted the tradeoff between the application update rate and the number of nodes in a network [21,22]. However, it has to be highlighted that most of the results are limited to Class A devices, whereas very few extend the analysis to Class B [23,24].
Leveraging on a part of the results described in previous authors' work [25][26][27], some considerations about the coverage of a single gateway, limited by the actual link budget, can be sketched. In particular, if a typical outdoor urban scenario is taken into account, previous experiments demonstrated that the communication range is on the order of few kilometers. When indoor scenarios are addressed, the very high sensitivity of LoRa radios still permits covering multiple rooms located on different floors.

The Proposed Communication Architecture
A schematic block diagram representing the proposed LoRaWAN communication architecture for the coordination of smart IPSs is depicted in Figure 4.
It has to be highlighted that previously introduced end device classes only refer to the way the downlink messages are managed, whereas uplink messages are always handled in the same way. In the considered application, power supply is not a stringent constraint, and Class-C operation could be a useful choice for reducing the latency in receiving messages from the IPSs coordinator. However, it is well-known that the ALOHA-like random access medium access strategy adopted in LoRaWAN has limited throughput (despite the time and power capture effects mitigating the worst case 18% of pure ALOHA) that is also severely affected by uncoordinated downlink transmissions [28]. The easiest way to improve the overall network performance is to provide some synchronization strategies for coordinating message transmissions, reducing the vulnerability time (i.e., the time interval in which the sent frame can suffer from collisions). It could be possible to implement a time dissemination mechanism for a Class-C device, but this would completely depend on the application layer implementation, thus greatly lowering the time accuracy. On the contrary, Class-B defines the Beacon-based synchronization mechanism implemented at the data link level. The Class-B downlink message transmission follows a Slotted-ALOHA-like medium access strategy, enhanced by further adding slot selection randomness to reduce the frame collision probability. Moreover, it has also to be underlined that Class-C extends the RX2 window, which, as reported in the specifications, "uses a fixed frequency and data rate". Thus, a change in the data rate affects all messages received in the RX2 window, including those related to Class-A devices. On the contrary, Class-B allows for specifying a data rate for synchronized downlink messages only, resulting in a more flexible approach. For all these reasons, in this work, Class-B operations have been considered. In the typical scenario, as that depicted in Figure 5, a GW is located close to the PCC with the main MV utility grid, while the backend servers allow all the different type communications required by the considered application, i.e., with other smart protections installed in the user's main substation; with the DSO communication infrastructure (e.g., for the provisioning of remote signals); and with the user's local network (e.g., for the system monitoring). Each IPS is connected to or embeds a LoRaWAN node. Indeed, digital input can be used for legacy IPs, while direct integration can be considered for new smart IPs.
Each IPS transmits uplink messages containing its identification code, the operating status (i.e., normal versus TRIP or START mode), the triggering event (if any, as the triggered protection function), and, possibly, the triggering value (i.e., the voltage or frequency value, or the connection timeout, causing the protection function activation). The IPS identification code can be configured by the system (i.e., by the application server) and is used to allow the implementation of the monitoring of the communication between the IPS and the LoRaWAN infrastructure. The possible time interval between consecutive uplinks can be on the order of few seconds, depending on the adopted SF, on the number of coordinated nodes, and on the selected TP value. The data model describing the structure of uplink messages is presented in Table 1. Based on the proposed data model, a 5 B message must be transmitted by IPSs to the LoRaWAN infrastructure for each uplink transmission. On the other hand, once the system is configured, multicast messages are sent to all the LoRaWAN-enabled IPSs, in order to coordinate the devices in the occurrence of possible islanding events detected in the system. Possible coordination commands include: the TRIP of all of the installed IPSs generated by the TRIP of a single IP of the system (i.e., the application of the "OR logic" configuration); the TRIP or START of all of the installed IPSs following a residual voltage violation event; and a remote signal (e.g., TRIP, START, or 81V commands) triggered by the DSO. For the sake of robustness, an acknowledge field is embedded in the downlink message to monitor the communication status, as required by the regulatory framework. The data model describing the structure of downlink messages is presented in Table 2. The "message type" field is considered to allow the distinction between configuration messages (used during the first configuration of the system, e.g., for the assignment of IPS identification codes) and normal operation messages. The "coordination command" field is used to send commands to all the installed IPSs and can support up to 256 different commands. The acknowledge message is transmitted as a bitmap, where each n-th bit represents the success (bit = 1) or the fail (bit = 0) of the receipt of the m-th uplink message from the n-th node. Each m-th uplink message is traced by both the nodes and the GW by means of a counter, represented by the "cycle counter" field in the data model. The counter is reset (by all the nodes and by the GW) at each beacon message. In particular, the size of the acknowledge message depends on the expected number of IPSs which must be coordinated by the system. Since the maximum allowed size of a LoRaWAN message is limited to 51 B (if all the possible SF values are used), the maximum size of the acknowledge message is of 48 B, corresponding to a maximum of 384 allowed IPSs per network.

Scalability and Sensitivity Analyses
The aim of the scalability and sensitivity analyses is to determine the number of IPSs that can be handled by a single LoRaWAN gateway and the maximum expected time of response between a triggering event and the arrival of the related coordination command. The analyses were carried out by computing, per each SF (with SF ranging from 7 to 12) the Time-on-Air (ToA) duration of the monitoring and supervisory control messages introduced in the previous section. Different scenarios have been considered by varying the maximum number of mapped IPSs (i.e., by varying the size of the acknowledge message defined in the data model) and the value of the ping period TP.
Referring to the data model introduced in the previous section, every ping period, a 5 B uplink message is transmitted by each IPS to the LoRaWAN infrastructure, while a single multicast downlink message is transmitted by the LoRaWAN infrastructure to all the IPSs installed in the system. If we call R the size (in B) of the acknowledge message, the size (in B) of the multicast downlink message is equal to 3+R. Since R can vary between 1 B and 48 B, the total size of each downlink message ranges between 4 B and 51 B.
Since the size of all the uplink messages is fixed, the duration of each uplink transmission, ToAU, depends only on the selected SF. Conversely, since the size of the multicast downlink transmission depends on the number M of mapped IPSs (with M = 8·R), the duration of multicast downlink transmissions, ToAD, depends both on M and on the selected SF. If we consider that, during each ping period (with a duration TP), the time reserved for uplink messages is equal to TP − ToAD, the maximum number of nodes per channel that can be managed by a single GW in a synchronized scenario, per each SF, can be computed as follows: where nsync(SF) is rounded to the lower positive integer. Once the value of nsync(SF) is determined, the maximum number of nodes per channel assuming the pure ALOHA access is determined as nALOHA(SF) = ALOHA·nsync(SF), by assuming ALOHA = 18%. The value of nALOHA(SF) is rounded to the lower positive integer. The value of maximum nodes per each SF is then computed by considering the adoption of the three compulsory LoRaWAN channel, and limited to the maximum number of mapped devices as defined in the data model definition: Finally, the maximum number of nodes that can be managed by a single GW is determined by considering all the available SF, and limited to the maximum number of mapped devices as defined in the data model definition: The maximum expected time of response between a triggering event and the arrival of the related coordination command is computed by assuming the scenario depicted in Figure 6. In this case, the triggering event (e.g., the TRIP of an IP) causing the need of a specific coordination command occurs just before the start time of the beacon guard time, and the related message is not immediately transmitted by the node to the GW. After the beacon guard time (TBG) and the beacon reserved time (TBR) have elapsed, the GW turns into the transmit mode, and then the triggering event message is transmitted by the node to the GW. Independently from the time of receipt of the triggering event message, an entire ping period TP must have passed before the related coordinating message is sent to all the installed IPSs. If this scenario is assumed, the maximum expected time of response TR depends on the considered ping period, by the number of mapped IPSs and by the selected SF. In particular, TR can be computed as follows: where TBG = 3 s and TBR = 2.12 s. A first sensitivity analysis was carried out to determine the maximum number of IPSs that can be managed by (a single) LoRaWAN GWs and the maximum expected response time by varying the number of devices mapped in the data model. The value of Nmax was computed using Equation (3), by varying M from 8 to 48 for two different scenarios: at the minimum allowed ping period (corresponding to k = 7), and at the maximum ping period (corresponding to k = 3). The value of k was limited to 3 (corresponding to a ping period of about 15.36 s) because, for lower values of k, the corresponding value of TP would exceed the response time limit of 30 s defined by the Italian regulatory framework.
As shown by the results depicted in Figure 7, if the highest ping period is considered, the maximum number of IPSs that can be managed by (a single) LoRaWAN GWs perfectly matches the number of devices mapped by the data model, up to a limit of 312 devices per network. Conversely, if the lowest allowed ping period is assumed, the maximum number of IPSs is limited to 12. Concerning the maximum expected response time, it can be noted that the latter is slightly affected by the number of mapped devices (with differences lower than 2 s), while it is sensibly affected by the chosen ping period, by ranging from 8.5 s for TP = 0.96 s (with 312 mapped devices) to 22.9 s for TP = 15.36 s (with 312 mapped devices).
A further sensitivity analysis was carried out to determine the maximum number of IPSs that can be managed by (a single) LoRaWAN GWs and the maximum expected response time by varying the ping period. The value of Nmax was computed using Equation (4), by varying k from 3 to 7 (i.e., corresponding to a ping period of 15.36 s and 0.96 s, respectively) for two different scenarios: for 32 and for 312 mapped devices. As shown by the results depicted in Figure 8, the maximum number of IPSs grows by increasing the duration of the ping period, by reaching the limit of 32 devices of the first scenario at 1.92 s, while exponentially increasing up to 312 devices at 15.36 s in the second scenario. On the other hand, the maximum expected response time grows exponentially by increasing the ping period, by varying from 8.54 s to 22.94 s (with 312 mapped devices). It must be also noted that, for the two considered scenarios, the difference of the maximum expected response time is negligible (less than 2 s). The detailed analysis of the scalability of the proposed solution was finally carried out for the two scenarios described above, i.e., with up to 32 and up to 312 mapped devices.
In Table 3, the duration of the uplink and downlink messages for scenario with up to 32 mapped devices are reported for each SF. The values have been computed by referring to the standard LoRaWAN specifications. Based on these values, the maximum number of coordinated IPSs for each SF, depending on the selected ping period, is reported in Table 4, and then depicted in Figure 9. Similarly, the maximum expected response time for each SF, depending on the selected ping period, is reported in Table 5, and then depicted in Figure 10.    As it can be noted, the maximum number of coordinated devices is reduced only in the case the lowest ping period duration is adopted (which allows only 12 total devices). However, some relevant limitations can be noted concerning the use of high SF values (i.e., for SF from 10 to 12) if a ping period duration lower than 7 s is applied. In this case, the coordination of IPSs is very limited, or even not possible for ping periods lower than 2 s. In addition, it must be noted that the highest number of coordinated IPSs for the highest SF values is limited to nine devices for SF = 11 and to three devices for SF = 12. On the other hand, it can be noted that the maximum response time is scarcely affected by the SF, while strongly depending on the selected ping period, with values ranging from 6.14 s (corresponding to TP = 0.96 s, and SF = 7) to 21.8 s (corresponding to TP = 15.36 s, and SF = 12).
In Table 6, the duration of the uplink and downlink messages for scenario with up to 312 mapped devices are reported for each SF. The values have been computed by referring to the standard LoRaWAN specifications. Based on these values, the maximum number of coordinated IPSs for each SF, depending on the selected ping period, is reported in Table 7 and then depicted in Figure  11. Similarly, the maximum expected response time for each SF, depending on the selected ping period, is reported in Table 8 and then depicted in Figure 12.    In the scenario with up to 312 mapped devices, the maximum number of coordinated devices is remarkably affected by both the selected SF and by the adopted ping period. In particular, the number of IPSs that can be managed by a single LoRaWAN base station ranges from 312 devices in the case of TP = 15.36 s, to only nine devices for TP = 0.96 s. Similarly to the results obtained in the scenario with up to 32 mapped devices, in the second scenario, the number of allowed IPSs is also very limited for high SF values, particularly from 10 to 12. It is interesting to note that the same results are shown by both the considered scenarios for SF from 10 to 12, for each ping period. On the other hand, the maximum response time is scarcely affected by the SF, while strongly depending on the selected ping period, by showing values very close to that obtained for the scenario with up to 32 mapped devices.
If applied to the use case presented in Section 3, it can be concluded that the proposed LoRaWAN architecture would be able to manage all the installed IPSs, by providing monitoring and coordinated control functions with a maximum expected response time of about 10 s, thus in compliance with the current Italian regulatory framework on the matter. In addition, it must be noted that the adoption of the proposed communication architecture would allow for overcoming the main drawbacks of the currently deployed infrastructure, i.e., scarce scalability, low reliability, and scarce flexibility. The proposed solution would in fact allow the implementation of coordination and monitoring functions (which cannot be implemented by the current system), and its expansion to a larger number of installed DER units. Theoretically, up to 312 devices could be in fact managed by a single GW, by assuring a maximum response time compliant with the current Italian grid codes.

Conclusions
In this study, a proper communication architecture based on the LoRaWAN Class B technology was proposed for the coordination of interface protection systems in smart grids. A suitable data model structure was determined to allow the computation of the payload of the communication. A scalability analysis on the application of the proposed LoRaWAN architecture was then proposed, by computing the number of devices that can be handled by a single LoRaWAN gateway and the maximum expected time of response between a triggering event and the arrival of the related coordination command. The analysis was carried out by computing the Time-on-Air duration of monitoring and supervisory control messages, by varying the ping period time interval and the number of devices mapped in the data model.
The results of the study showed that, considering the duty cycle limitation of LoRa, up to 312 devices can be managed by (a single) LoRaWAN GWs, by assuring a theoretical maximum response time of 22.95 s, which complies with the current regulatory frameworks on the matter. It must be noted that lower response times can be obtained by reducing the ping period interval (up to 6.2 s can be obtained by using a ping period of 0.96 s), but by strongly limiting the number of coordinated devices (no more than 12, if a ping period of 0.96 s is used). In addition, the lower the ping period is, the lower is the possibility of managing devices by using high SF values. In particular, if the lowest ping period of 0.96 s is used, only SF 7 and 8 are available (i.e., devices cannot be reached by SF greater than 8). Finally, it must be noted that, even if up a total amount of 312 devices can be managed by (a single) LoRaWAN GWs, the number of IPSs that can handled by high SF values is very limited. In particular, the highest number of coordinated IPSs is limited to nine devices for SF = 11 and to three devices for SF = 12. Funding: This research activity has been partially funded by University of Brescia as part of the joint research activities of the laboratories "energy Laboratory as University eXpo -eLUX", and by Unareti S.p.A. under the research contract "Sharing Cities".

Conflicts of Interest:
The authors declare no conflict of interest.

Appendix A. Protection Functions Implemented by IPSs
In the following, the typical protection functions provided by IPSs are defined by referring to the current Italian regulatory framework, which is schematically represented in Figure A1. Figure A1. IPS protection functions defined by the current Italian regulatory framework. Blue blocks represent functions which are locally implemented by IPs. Green blocks represent functions which can be either implemented locally by IPs, or, remotely, from other protections installed in the system, or by remote commands (e.g., by the DSO). Purple blocks represent functions that are implemented remotely by the DSO. Red blocks represent local signals which must be coordinated between all the installed IPs and IDs.
The definition of the requirements for the connection of active and passive users to HV and MV DNs, and to LV DNs, are provided in Italy by the standards CEI 0-16 [29] and CEI 0-21 [30], respectively. The protection functions represented in Figure A1 are characterized by acceptable bands of voltage and frequency values, which are measured by the IP or by external sensors. Each IP is responsible for provisioning the related control signal (following the TRIP state of the protection) to one or more connected IDs. IDs may be installed both on LV lines and on MV lines. When multiple IDs are controlled by a single IP, they must operate in OR configuration, such that the detected anomaly causes the opening of all the connected IDs.
Inside each IP, the part of the device reserved to the voltage and frequency measurements (called measuring section) must be placed upstream from the DG unit, and can be connected both on the LV line and on the MV line, depending on the position of the associated ID (for LV or for MV, respectively). Only one exception exists, which concerns the implementation of the function 59N (i.e., the violation of the residual voltage thresholds). This function requires the measurement of the homopolar voltage on the MV line, which is usually performed by means of an open triangle Voltage Transformer (VT). In detail, when the IPS is installed on the LV line (e.g., DG units installed in nested LV sections for practical reasons), two different implementations of the 59N function can be chosen, namely the "direct mode" and the "indirect mode". The direct mode is applied if the IPS is close to the residual VT, while the indirect mode is applied when there are long distances between the IPS and the residual VT. In the direct mode, the secondary stage of the VT is connected to the LV measuring section of the IP, which in turn directly implements the 59N function. In the indirect mode, the 59N function is implemented by means of remote TRIP and START signals, which are sent from a dedicated IP to all the other IPSs. In the latter case, an additional protection device (here called IP 59N) must be installed near the residual VT. The IP 59N device measures the homopolar voltage; then, it autonomously applies the 59N function. It sends the TRIP signal to the other IPSs (causing the opening of all of the related IDs), and the START signal (enabling the voltmeter release function, which means the transition from the permissive thresholds to the restrictive thresholds). In the case of communication failure between the IP 59N and the IPSs, the latter must turn into TRIP condition, thus requiring the implementation of dedicated monitoring system.

Appendix B. The Communication System of the Considered Use Case
In the following, the description of the IPS communication system implemented in the considered use case is reported in detail. A map representing the set of RES and ESS equipment installed in the Engineering campus of the University of Brescia is depicted in Figure A2. As already introduced in Section 3, the IPSs installed in the Engineering campus of the University of Brescia are configured as uncoordinated IPSs, i.e., without implementing the "OR logic" configuration, while the protection function 59N is implemented by means of a dedicated IP (IP 59N) placed at the MV substation of the campus. An alternating current (AC) circuit at 230 V connects the IP 59N and the IPSs. The START signal is provided as a clean contact implementing a digital input of each IP; the input state resembles the lack or presence of voltage (230 V) between the signal cable (phase) and the neutral of the AC power supply line of the IP 59N. On the other side, the TRIP59N cable is connected to the power supply of the TRIP relay (actually an input) of each IP. Sharing the phase and the neutral of the PI 59N, and of all the IPs present in the system, respectively, allows for implementing the minimum voltage circuit among the IP 59N and the individual IPs. An Uninterruptible Power Supply (UPS), supplied by an emergency LV line equipped with an auxiliary emergency generator, is present in the MV main substation of the end user and powers the IP 59N (single-phase AC). As a consequence of the system configuration, the implementation of a system devoted to the monitoring of the connection among the IP-59N device and the IPSs can be avoided. The monitoring of the TRIP of the installed IPSs is not required as well; indeed, in case of a lack of connectivity with the IP 59N (powering the ID), e.g. due to TRIP cable break, the IPS enters automatically into the TRIP mode. Finally, a GPS device connected to the PV-1 IPS implements the remote TRIP signal provided by the DSO. Consequently, when a remote TRIP from the DSO occurs, only the PV-1 generator is disconnected, since the currently available communication system does not allow the coordination of the other IPSs. Despite the fact that current Italian standards do not take into account such a configuration, the authority considers it acceptable, as explained in the response to question no. 9 of the documents reporting guidelines for applying Annex M of CEI 0-16.