SYSTEM AND METHOD FOR QUANTUM-SECURE MICROGRIDS CROSS REFERENCE TO RELATED APPLICATIONS [0001] This application claims the benefit of U.S. Provisional Application Nos. 63/223,751 filed on July 20, 2021 and 63/325,210 filed on March 30, 2022, the entirety of each of which is incorporated by reference. STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT [0002] This invention was made with government support under ECCS-2018492 and OIA-2040599 awarded by National Science Foundation. The government has certain rights to this invention. FIELD [0003] The present application relates generally to a system and method for secure communications and more specifically systems and methods for quantum-secure microgrids and quantum network—based microgrid operations. BACKGROUND [0004] Securing data transmission in microgrid is critical for maintaining normal grid operations and achieving desirable benefit, e.g., fast recovery during a main grid blackout, improved system reliability and resilience, and economic power supply to customers. Existing methods on this topic largely rely on cryptographic systems such as the Advanced Encryption Standard (AES), the One-Time Pad (OTP), and similar methods. [0005] The security of AES, OPT, and other symmetric-key cryptographic systems relies on classical public key system which are vulnerable to attacks from quantum computers. Classical public key systems used in networked microgrids (NMGs) to distribute keys for two communicating parties are secured based on the assumed limits on an adversary’s power, i.e., the mathematical problems such as the discrete logarithm problem [1] or the factoring problem [2] cannot be efficiently solved even by the fastest modern computers with any existing algorithms. This mathematical assumption however can be broken by attacks from quantum computers, as quantum computing promises to efficiently solve mathematical problems. Although today’s quantum computers are still noisy and their advent on a degree powerful enough to break current cryptographic systems is perhaps still decades away, their sudden appearance will leave microgrid organizers little time to adapt. [0006] A potent solution to tackle this quantum-era challenge is to use the quantum key distribution (QKD). QKD provides information-theoretic security through the laws of physics. Those laws have been fairly heavily tested and provide a more solid foundation than computational assumptions. Different protocols have been proposed to implement QKD including the well-known BB84, decoy-state, six-state, Ekert91, and BBM92. However, while QKD has been extensively analyzed and widely applied in areas such as computer networks, online banking, ATM transactions, e-voting systems, and portable applications, the microgrid community is unfortunately largely silent on the topic of developing quantum-secure networked microgrids (NMGs). In the context of quantum secure NMGs, the existing QKD systems however cannot be directly applied. With multiple data transmission channels existing in NMGs, it is unclear how the QKD’s performance will be in the system. A real-time QKD-enabled NMGs simulation testbed for evaluating the performance of the system is significantly needed but does not yet exist. [0007] Furthermore, the key generation speed in a QKD system is affected by various factors such as the distance between two communicating parties and the noise, which can be either natural or caused by an adversary, on quantum optic equipment. A large distance or a strong attack on the QKD equipment can unfortunately reduce the speed, detrimentally causing keys to be exhausted. A proper strategy is therefore needed to improve the cyberattack resilience for the system. SUMMARY [0008] Accordingly, disclosed are systems, methods and computer program products for a QKD-based communication architecture for NMGs. [0009] In one aspect there is provided a practical decoy-state protocol utilized to implement QKD. [0010] In a further aspect there is provided a QKD-integrated quantum-secure NMGs testbed in an RTDS environment, including the hardware connection, communication network design, and QKD integration. [0011] Further to this aspect, there is provided, a novel two-level key pool sharing (TLKPS) strategy to improve the system’s cyberattack resilience. Extensive tests are implemented on the testbed. Test results validate the effectiveness of the presented strategy, and provide insightful resources for building quantum-secure NMGs. [0012] In a further aspect, systems and methods described herein address the cyber- resilience of QKD-based microgrids by leveraging software defined networking (SDN). [0013] In accordance with a first aspect of the invention, there is provided a communications system for a plurality of microgrids. The system comprises: a first microgrid and a second microgrid, the first and second microgrids providing power to a load, a quantum channel connecting the first and second microgrids, the quantum channel adapted for distributing quantum generated keys between the first microgrid and second microgrid; one or more key pools associated with the first and second microgrids for storing quantum generated keys; a controller associated with a microgrid, the controller configured for determining a number of key bits in one key pool and comparing the number of key bits against a pre-determined threshold; and upon determining a number of key bits is below the pre-determined threshold, sharing a certain number of key bits from another key pool. [0014] In a further aspect, there is provided: a quantum key distribution system for networked microgrids. The system comprises: one or more microgrids, each microgrid providing a supply of power to loads and obtaining measurements from different loads associated with use of a microgrid; a controller associated with a microgrid and employing control signals associated with communications among the one or more microgrids and between the microgrid and a local controller associated with the microgrid; at least one key pool associated with one or more of the microgrids, the microgrid using quantum generated keys associated with key bits supplied from each of the at least one key pool for communications among the one or more microgrids and between the microgrid and its associated local controller, a key consumption speed associated with a rate of the communications among the one or more microgrids, wherein the controller at the microgrid is configured to transmit measurements at the microgrid as real-time messages from the microgrid to its associated local controller using a quantum generated key supplied from the key pool; and the controller at a microgrid employing a two level key pool sharing strategy to ensure there are enough key bits in each key pool. [0015] In a further aspect, there is provided a method for operating a plurality of microgrids. The method comprises: providing a system having a first microgrid with a second microgrid, the first and second microgrids providing power to a load, and a quantum channel connecting the first and second microgrids, the quantum channel for distributing quantum bits between the first microgrid and second microgrid to generate secret keys; providing one or more key pools associated with the first and second microgrids, the one or more key pools for storing quantum generated keys; determining, using a controller associated with a microgrid, a number of key bits in one key pool and comparing the number of key bits against a pre-determined threshold; and upon determining a number of key bits is below the pre-determined threshold, sharing a certain number of key bits from another key pool of the one or more key pools. [0016] Further features as well as the structure and operation of various embodiments are described in detail below with reference to the accompanying drawings. In the drawings, like reference numbers indicate identical or functionally similar elements. BRIEF DESCRIPTION OF THE DRAWINGS [0017] FIG.1 illustrates a general setting of a QKD-based communication system in an aspect of the disclosure; [0018] FIG.2 depicts a QKD-based quantum-secure NMGs architecture; [0019] FIGs.3A-3D depict differences between QKD networks and quantum NMGs where FIG.3A depicts a typical QKD network; FIG.3B illustrates a first scenario of an attack within a single microgrid; FIG.3C illustrates a second scenario of an attack between two microgrids without an alternative QKD path; and FIG.3D is a third scenario depicting an attack between two microgrids with an alternative QKD path; [0020] FIG.4 depicts a two-level key pool sharing (TLKPS) strategy according to an embodiment; [0021] FIG.5A illustrates a first level of the TLKPS strategy; [0022] FIG.5B illustrates a second level of the TLKPS strategy; [0023] FIG.6A depicts an example testbed for QKD-enabled quantum-secure NMGs in a RTDS; [0024] Fig.6B depicts a high-level design of the testbed illustrated in FIG.6A; [0025] FIG.6C depicts the network connection of key components in the RTDS simulator and a flow chart of the algorithm running in the MGCC; [0026] FIG.7 depicts a network topology for the QKD-enabled quantum-secure NMGs in an embodiment; [0027] FIG.8 depicts a one-line diagram of the NMGs model in an exemplary embodiment; [0028] FIG.9 depicts an example key generation speed with different distances and noises with each packet consisting of 64 bits in an embodiment; [0029] FIG.10 depicts an example voltage response of a bus 1 before and after the key bits are used up in the example NMG model of FIG.8; [0030] FIG.11A shows a comparison of results of different key pools’ (KPs’) sizes without TLKPS; and FIG.11B shows a comparison of results of different KPs’ sizes with TLKPS when only the quantum channel between MG A and MG C is attacked; [0031] FIG.12A depicts a comparison of results of the numbers of key bits in KPAA, KPAB and KPAC without TLKPS (FIG.12A) and with TLKPS (FIG.12B) in a multi- attack scenario; [0032] FIG.13 depicts a flow chart of the QKD simulator in an embodiment; [0033] FIG.14 depicts an architecture of the QKD- and SDN-enabled microgrid according to an embodiment; [0034] FIG.15 depicts the use of lookup tables in the SDN controller according to an embodiment; [0035] FIG.16 depicts a logic diagram of the event detection in one embodiment; [0036] FIG.17 depicts a flow chart representing the procedures of the SDN controller for the E1 event according to an embodiment; [0037] FIG.18 depicts a timing diagram of data packets received by the SDN controller during two events according to an embodiment; [0038] FIG.19 depicts a QKDS+ simulator method according to a further embodiment; [0039] FIG.20 depicts a further QKD- and SDN-enabled microgrid real-time test environment according to an embodiment; [0040] FIG.21 depicts a hardware connection and the flow chart in the microgrid control center (MGCC) of FIG.20; [0041] FIG.22 shows a further embodiment of a microgrid model utilized in an embodiment; [0042] FIG.23A shows the QKD performance with different fiber lengths and the number of key bits; and FIG.23B shows the QKD performance with different fiber lengths and the numbers of classical bits generated from Alice and Bob; [0043] FIG.24A depicts example test results of dynamic routing with the number of stored key bits and the total number of classical bits generated from Alice and Bob before and after dynamic routing; and FIG.24B depicts example test results of dynamic routing with the traffic captured in the two paths; [0044] FIGs.25A, 25B give the test results of rate limitation with number of stored key bits under rate limitation (FIG.25A), and the traffic captured with and without rate limitation (FIG.25B); [0045] FIG.26 depicts the effectiveness of firewalls with FIG.26A depicting power generated by each DER and the system frequency before and after a fake control signal is received; and FIG.26B depicts the traffic (from the attacker’s IP address) captured with and without firewalls; [0046] FIG.27A depicts a quantum repeater-based communication and in particular, a quantum repeater; and FIG.27B depicts a quantum repeater chain; [0047] FIG.28 illustrates a QNetGrid architecture according to an embodiment; [0048] FIG.29 depicts an example of QNetGrid quantum network with FIG.29A depicting an example quantum network of a 5 × 5 grid; FIG.29B depicting a quantum link connecting two quantum nodes and the intra-node entanglement; and FIG.29C depicting the installing of more links around the control center; [0049] FIG.30 depicts a QNSim algorithm according to an embodiment; [0050] FIG.31 shows a quantum routing for QNetGrid with FIG.31A depicting when there are two or more neighbors that can connect to the control center at the same minimum cost; FIG.31B depicting when the node priority is “a” to “y” in an embodiment; [0051] FIG.32A depicts example three DER placements in QNetGrid including two example scenarios 1 and 2 (e.g., Corner and Diagonal) and FIG.32B showing a third example scenario (e.g., Distributed); [0052] FIG.33 depicts a one-line diagram of the communication-based six-microgrid system in an embodiment; [0053] FIG.34 depicts a QNetGrid testbed according to an embodiment; and [0054] FIG.35 depicts the hardware connection in the QNetGrid testbed of FIG.34. DETAILED DESCRIPTION [0055] The following detailed description of aspects of the disclosure will be made in reference to the accompanying drawings. In this disclosure, explanation about related functions or constructions known in the art are omitted for the sake of clearness in understanding the concept of the disclosure to avoid obscuring the disclosure with unnecessary detail. [0056] QKD is a key-growing method used to generate and distribute secret keys for two distant parties. It utilizes the fundamental properties of quantum mechanics, which are resilient against increasing computational power, improved computational algorithms, and quantum computers. A QKD system, in general, consists of a quantum channel, i.e., a fiber or free space, and a classical one, i.e., a public but authenticated communication link. Quantum states are first transferred through the quantum channel between the sender and the receiver for generating raw keys. After the transmission and measurement of the quantum states, the corresponding postprocessing steps are performed over the classical channel to distill the final secret keys. With the generated keys, data messages are encrypted and transmitted over the classical channel. [0057] Over the years, a variety of QKD protocols have emerged, many of which have been experimentally demonstrated in real-world scenarios. In general, there are two types of QKD. One is the discrete-variable QKD (DV-QKD), where quantum information is encoded in discrete variables, and single-photon detectors are used to measure the received quantum states, and thus, the measured results are discrete. Examples of DV-QKD are the BB84 protocol and the E91 protocol. Alternatively, the other type, continuous-variable QKD (CV-QKD), encodes quantum information in the phase and amplitude quadratures of a coherent laser and uses homodyne detectors to measure the received quantum states where the measured results are continuous. Examples include the Gaussian-modulated CV-QKD. [0058] The systems and methods described herein provide for a QKD-based communication architecture for NMGs and particularly address the cyber-resilience of QKD-based microgrids. [0059] In embodiments, the systems and methods described herein address the cyber- resilience of QKD-based microgrids by leveraging software defined networking (SDN). [0060] Specifically, the systems and methods provide: 1) a novel QKD- and SDN- based communication framework devised for microgrids; 2) three practical SDN applications developed to improve the system's resilience; 3) a complete QKD simulator; and 4) a QKD- and SDN-enabled cyber-physical prototypes built in an RTDS environment using real Pica8 SDN switches. [0061] The prototype includes a “hardware-in-the-loop” testbed that provides a realistic testing environment, and can significantly benefit the power grid community by promoting the adoption of quantum techniques. [0062] The systems and methods integrate both quantum key distribution (QKD) and software defined networking (SDN) into a real-time power system simulator, i.e., RTDS, using real SDN switches. Unlike other power system testbeds, this testbed has its unique feature, i.e., the quantum key generation and key consumption are integrated in a microgrid context where the generation speed is determined by a complete QKD algorithm and the consumption speed is affected by the real data transmission managed by the SDN controller over real SDN switches. This design presents a realistic cyber- physical testing environment with both SDN and QKD features incorporated. [0063] FIG.1 illustrates a general setting of a QKD-based communication system 10. QKD-based communication system 10 consists of a quantum channel 15 and a classical channel 20. The quantum channel allows two parties, commonly named Alice 12 and Bob 14, to share quantum bits (or qubits) for creating raw keys that are partially secure and secret. The generated raw keys are processed through postprocessing over a classical channel 20 to produce secure keys 30 used for tasks such as encryption and authentication. With the created keys 30, the information to be transmitted is encrypted and later decrypted over a classical communication channel 20. The produced secure keys are stored in a key pool (KP) 25, and will be extracted later from the KP for encryption and decryption. The security of a QKD protocol, in a way, takes advantage of this: by encoding a classical bit string using different, randomly-chosen bases, an adversary who is unaware of the basis choice can never be truly certain of the information being transmitted. Furthermore, any attempt to actually learn this information causes noise in the quantum channel which can be detected by the two parties later. [0064] In embodiments herein, adversaries have complete control over all quantum communication channels along with perfect quantum memories. In addition, they are free to perform an optimal attack on the quantum communication utilizing any computational capability available now or in the future (e.g., using quantum computers). The security guarantees the QKD-produced keys are information theoretic in that they do not make any assumptions on the computational abilities of the adversary. Thus, the keys derived are secure even against future computational or algorithmic breakthroughs. In embodiments, devices internal to communication nodes (e.g., quantum sources and quantum measurement devices) are assumed trusted and cannot be tampered with by the adversary. [0065] Finally, it is assumed an authenticated classical channel 20 connects the two parties 12, 14. Such channels are needed for QKD systems to operate and provide information theoretic authentication (but not secrecy). These authentication tags, being also information theoretic secure, are secure against future computational or algorithmic breakthroughs (e.g., they are secure against a future quantum computer). [0066] QKD-based microgrids and NMGs according to embodiments of the present dis closure are now presented in view of FIG.2. In a single microgrid, a control center is typically in charge of collecting data from customers, handling the received data for various operating functions, and sending control signals to corresponding local controllers to regulate the power output of certain distributed energy resources (DERs). In the example networked MGs system illustrated in FIG.2, QKD systems are installed for the communications between the control center and local controllers as those communications are considered relatively more critical. [0067] In particular, FIG.2 depicts a QKD-based quantum-secure networked microgrids (NMGs) architecture 75. As shown in FIG.2, the NMGs system consists of multiple interconnected MGs 50A, 50B, 50C. Within each MG, a microgrid control center (MGCC) 60A, 60B, 60C collects information from customers, e.g., loads 40, and sends corresponding control signals to local controllers. [0068] For the QKD-enabled NMGs, QKD systems are installed not only for the communications between each control center and local controllers in the same microgrid but also for the communications between two neighboring microgrids. QKD- based NMGs differ from conventional QKD networks in several aspects. For instance, in a QKD network, two communicating parties can be far remote; in NMGs, however, two communicating parties are normally geographically close. As a result, while there are multiple QKD paths existing between two remote parties in a QKD network, only one or limited QKD paths exist between two communicating parties in NMGs. Additionally, a common QKD node in QKD networks and a control center in NMGs have different levels of security, trustfulness, and reliability. [0069] In this architecture of FIG.2, QKD is utilized to generate keys for communications between each MGCC and local controllers in the same MG, while the communications between each MGCC and customers in the same MG are established over classical channels. The keys used for the communication between two MGCCs in different MGs are also generated using QKD. [0070] Note that, because from the economic perspective, building a quantum link is costly; therefore, quantum channels are only allocated for important communications. Keys generated by different quantum channels are stored in separate key pools (KPs). [0071] Ideally, the key generation speed in a QKD system has to be large enough to guarantee there are always enough keys in the KP. However, this speed can be affected by a variety of factors such as the distance between two communicating parties and the attack on quantum optic equipment. To maintain normal operations in the QKD- enabled NMGs, a proper strategy is needed in case the bits in any KP are used up. [0072] Keys produced by QKD are unconditionally secure because by using different, randomly chosen bases to encode classical bits, an adversary with little knowledge on the basis choices cannot truly obtain the information being transmitted. Further, any eavesdropping attack on the quantum channel causes noise which can be detected by the two parties. [0073] However, this inevitably introduces Denial of Service (DoS) attacks. Any DoS attack on quantum optical equipment increases noise and causes key establishment sessions in a QKD system to be aborted, potentially leading to the exhaustion of keys. [0074] There are existing works on mitigating DoS attacks for QKD networks. However, while the approaches are applicable for QKD networks, they are not suited for quantum NMGs. The difference between QKD networks and quantum NMGs is illustrated in FIG.3. As shown in FIG.3A, in a QKD network, multiple QKD paths exist between two nodes, and hence, when one path is attacked, an alternative path can be switched to. For instance, Nodes 1 and 4 can select not only Paths 1–2–4, but also Paths 1–3–4, 1–2–3–4 and 1–3–2–4 to distribute keys between them. [0075] However, a quantum NMGs system typically has only one quantum path between two communicating parties, i.e., a MGCC and a local controller, or two neighboring MGCCs. Based on the NMGs topology and location of the attack on the system, three cases exist as follows. [0076] 1) Scenario 1: The KP that lacks key bits is within a single microgrid, i.e., between a MGCC and a local controller. [0077] 2) Scenario 2: The KP that lacks key bits is between two microgrids that do not have an alternative QKD path. [0078] 3) Scenario 3: The KP that lacks key bits is between two microgrids with an alternative QKD path. [0079] Most communications in NMGs fall under Scenarios 1 and 2 as shown in Fig. 3B and 3C, where there is only one QKD path between two communicating nodes. The traditional method for QKD networks, i.e., reselecting an alternative QKD path, is however infeasible in these cases. Generally, few situations are under Scenario 3 when an alternative QKD path exists between MGCCs A and B (i.e., MGCC A–G–B) as shown in Fig.3D. [0080] To mitigate the impact of DoS attacks on quantum NMGs, there is presented a software-defined adaptive post-processing (SDAPP) approach and a two-level key pool sharing (TLKPS) approach (a TLKPS strategy). Specifically, SDAPP is launched to improve QKD’s performance during the DoS attack, and TLKPS is performed when the number of bits in a KP is below a predetermined threshold. [0081] In one embodiment, FIG.4 provides a two-level key pool sharing (TLKPS) strategy 100. Input to the algorithm 100 are parameters 105 including: a threshold Th, which restricts the minimum number of bits in a KP, a number of bits Ns, and the actual QKD configurations. The algorithm output includes the number of bits in each KP that is above threshold Th. In sum, a threshold Th, which restricts the minimum number of bits in a KP, is first determined. If the number of bits in each KP is below Th, a given number of bits will be shared from other KPs. Let KPij be the KP between MG i and MG j, Nij the number of bits in KPij , and Ns the number of bits sent to KPij . Then, if Nij is below Th, Ns bits will be sent to KPij. For example, as shown in FIG.3, upon initializing the NMGs system configuration, a FOR loop 110 is entered pertaining to each KPij between MG i and MG j. A determination is first made as to whether Nij < Th, and if so, a further determination is made to determine whether there exists MG k && Nik > (Th + Ns) && Njk > (Th + Ns). If such a statement holds then, Ns bits are shared from KPik and KPjk to KPij at 120. Otherwise, according to a second level KPS strategy, if it is determined at 125 that Nii < Njj, then Ns bits are shared from KPjj to KPij at 130; Otherwise, Ns bits are shared from KPii to KPij at 140, FIG.4. [0082] FIGs.5A and 5B illustrate the TLKPS strategy according to embodiments herein. The TLKPS strategy consists of two levels of bit-sharing from other KPs to KPij . FIG.5A depicts a first level of the TLKPS strategy. As illustrative of an exemplary scenario of the first level TLKPS strategy of FIG.5A, a NMGs system is shown as including three microgrids MG i, MG j, and MG k having classical communication channel interconnections and quantum communication channel interconnections therebetween. As shown in FIG.5A, there is a first key pool KPik 150 providing quantum generated keys for use in communications among microgrids MG i and MG k, and a second key pool KPjk 151 providing quantum generated keys for use in communications among microgrids MG j and MG k. [0083] In the TLKPS strategy, there consists of two levels of bit-sharing from other KPs to KPij. According to embodiments herein, when there exists MG k that establishes KPs with both MG i and MG j, and the numbers of bits in KPik and KPjk are both above (Th + Ns), Ns bits can be shared to KPij using the first level of TLKPS. In this case, MG k is utilized as an intermediate node to distribute keys between MG i and MG j as shown in FIG.5A. Here, MG k and MG i both extract a string of bits (i.e., Ns bits) 152 from KPik 150, and MG k and MG j both extract the same number of bits 154 from KPjk 151. MG k then processes these extracted bits, e.g., performs exclusive- OR operation at 156 and XORs the extracted two bit strings, and sends the result to MG j. MG j performs the same logic function at 158, e.g., XORs the received bit string with the bit string extracted previously from KPjk. The result obtained by MG j will be exactly the same as the bit string extracted by MG i from KPik. In this way, a string of bits is securely transferred from KPik and KPjk to KPij. Note that this first level of TLKPS still maintains information-theoretic security, and therefore is given the first priority in TLKPS. [0084] In a further embodiment, there is addressed a scenario when there is no such intermediate MG, or attacks are performed on multiple links, making intermediate MGs fail to share enough bits. The second level of TLKPS is thus established as shown in FIG.5B. As shown in FIG.5B, instead of using an intermediate MG to share keys to KPij, the second level of TLKPS utilizes the KP inside MG i (denoted as KPii) or the KP inside MG j (denoted as KPjj). When Nij is below Th, a string of bits is extracted from KPii (or KPjj depending on which KP has more bits). This bit string is then used as a plaintext, encrypted by MGCC i via a key extracted from KPij (note there are still some keys left in KPij ), and sent to MGCC j. MGCC j uses the same key from KPij to decrypt the received message and obtains the bit string. A bit string is thus transferred from KPii and is securely shared to KPij. Note that this AES-based key distribution loses information-theoretic security, and is performed when the first level of TLKPS fails. But it is still better than relying on public key systems because AES is considered quantum-secure. [0085] QKD-Enabled Quantum-Secure NMGs Testbed [0086] FIG.6A illustrates a design of a testbed for the QKD-enabled quantum-secure NMGs in RTDS, a real-time power system simulator. Specifically, the model of the NMGs is developed and compiled in RSCAD, a power system simulation software designed to interact with the RTDS simulation hardware. The RTDS in the testbed consists of three racks, which can be either used separately for small-scale power systems or combined together to provide more cores for a large-scale system. In FIG. 6A, computing system labeled “Rack 1” is utilized to simulate the NMGs in real-time, where the six cores in that rack are sufficient to provide high fidelity for the test results. [0087] The measurements from the RTDS simulator are sent to a remote server using Giga-Transceiver Network Communication Card (GTNET), e.g., GTNETx2 cards, which can, in real-time, either receive data from the RTDS and send it to external equipment, or receive data from the network and send it back to the RTDS, depending on whether they are designed to be in sending or receiving mode. The MGCCs in the NMGs run on the same remote server (they can also run on different servers). The server receives load measurements from the RTDS, and sends signals back to RTDS, with a 1 Gbps Ethernet connection. [0088] The high-level design of the testbed is illustrated in FIG.6B. Two GENETx2 cards are utilized for the purpose of network communication. It should be noted that, although only one quantum channel is established in this case, the principle can be easily extended to cases with multiple quantum channels. GTNETx2 card #2 is used to transmit data from the RTDS to the MGCC, which models the classical communication (represented in 1 in FIG.6B) in real-time, i.e., collecting load measurements to MGCC as shown in FIG.2. When the data is received by the MGCC, an analysis of the data is conducted, and proper control signals are sent to the local controller. Before a control signal is sent out, a key with the same length is extracted from the key pool. This process (represented in 2 in FIG.6B) succeeds only when there are enough key bits. [0089] GTNETx2 card #1 is utilized to receive signals from the MGCC (represented in 3 in FIG.6B) and transfer them to the RTDS. The simulation results with the updated control signals are demonstrated in RSCAD. Note that the QKD system is modeled using the QKD simulator described herein with resepct to FIG.13. Keys are continuously generated by the QKD algorithm, and are stored in a key pool. This real- time communication between the RTDS microgrid simulator and the MGCC using the QKD algorithm is the salient feature of this testbed. QKD-Based Microgrid Communication Network [0090] The network connection of key components in the RTDS simulator and a flow chart of the algorithm running in the MGCC are illustrated in FIG.6C. As shown on the left side of FIG.6C, each RTDS rack 170, 171, 172 is connected to one or more GTNETx2 cards using fiber optic cables. All the GTNETx2 cards are connected with an edge switch 175 through Ethernet cables to transmit and receive data over the network 180. The User Datagram Protocol (UDP) is used in the simulation. [0091] From the MGCC side, as shown on the right side of FIG.6C, the server enters the listening mode 190 after being connected to the simulator. At this stage, the server at 185 is receiving any UDP packet whose destination IP and port match those of the server, respectively. Once a packet arrives, a quantum key with the same length of the received data, e.g., 64 bits, is extracted at 192 from the key pool, and corresponding control signals are generated at 195. The server then enters the sending mode at 198 and starts to send out control signals whose destination IP and port are the IP and port of GTNETx2 card #1 in the RTDS simulator (see FIG.6A), respectively. After controller signals are sent out, the server goes back to the ^^^^^^^^^ mode 190. [0092] A QKD simulator capable of simulating the decoy-state BB84 protocol is developed in Python in the remote server. It simulates the probabilities of various events occurring such as multiple photon emission, photons being lost in the channel, phase errors, and detector imperfections. The simulator assumes quantum signals are continually being sent from end nodes building a raw-key pool. When the simulator is called, it determines how many signals could have been sent from the last call (based on the speed of the simulated laser source and detector dead times), what the user’s choices were for those signals (e.g., basis and intensity choices), and whether the receiver got a measurement outcome. If a sufficient number of signals have been sent the error correction and privacy amplification results are simulated leading to the generation of a simulated secret key of the actual size that would be generated under these conditions in practice. These secret key bits are added to the respective key pool. [0093] Quantum-Secure NMGs Communication Network [0094] FIG.7 depicts generally an exemplary network topology 200 for the QKD- enabled quantum-secure NMGs. In an embodiment, three MGs, MGA 201, MGB 202 and MGC 203 are interconnected with each other. In the testbed, the keys used for communications between two MGs and between a MGCC and a respective local controller (LC) are generated using separate QKD algorithms, and are stored in separate KPs. When there is a need to use keys, a certain number of bits are consumed from the corresponding KP. Two GTNETx2 cards are utilized for the communication between a LC in the RTDS simulator and each MGCC on the remote server. The User Datagram Protocol (UDP) is used in the simulation to transmit and receive data. [0095] The measurements in each MG are transmitted to its MGCC through one GTNETx2 card with a fixed speed set in RSCAD. The destination IP address is set as the IP address of the server, and the destination port is a specific number for the MGCC. Another GTNETx2 card is used for the LC to receive data from MGCC. Any UDP packet whose destination IP and port match those of this GTNETx2 card, will be received. [0096] From the MGCC side, each MGCC is receiving any UDP packet whose destination IP is the server’s IP and destination port match the MGCC’s port. When each MGCC receives a data packet from the RTDS, it sends out messages to other two MGCCs and a control signal to its LC. Two other ports are set for each MGCC to receive UDP packets from other two MGCCs. When each MGCC receives a data packet from another MGCC, a certain number of bits in the KP between the two MGCCs are deducted. NMGs Modeling [0097] A typical NMGs system 200 shown in FIG.8 is modeled to evaluate the performance of the QKD-enabled NMGs. This system is designed based on a medium- voltage MG with a battery and communication channels added. In an embodiment, three MGs, MGA 201, MGB 202 and MGC 203 are interconnected with each other. MG A 201 contains a photovoltaic (PV) system and a battery storage. A P-Q control is designed to regulate the output power of the battery, the value of which is determined by the real and reactive power references transferred from MGCC A. MG B 202 contains a diesel generator and a wind turbine. A droop control is utilized to regulate the output power of the diesel, the value of which is determined by the real and reactive power references transferred from MGCC B. MG C 203 contains a diesel generator, a PV system and a storage, where the storage uses a P-Q control whose real and reactive power references are given by MGCC C. Both the PV and wind turbine in the NMGs use the Maximum Power Point Tracking (MPPT) control to maximize their output powers. The information shared between two MGs includes the total power generation and the total load in each MG. Key Generation Speed with Different Distances and Noises [0098] The key generation speed is a critical metric in a QKD based system, as it determines the maximum data transmission speed. FIG.9 gives the experimental results of the key generation speed under different distances and noises, where each packet consists of 64 bits. It can be seen that 1) a small distance exhibits great superiority over a large one under the same noise, which gives valuable insights that two QKD parties should not be too far from each other; and 2) a large noise dramatically decreases the speed even with a small distance; this indicates that a proper strategy is significantly needed to improve the system’s resilience against attacks. Impact of Attacks on NMGs [0099] The impact of attacks on NMGs is evaluated. For a classical communication or a quantum communication when keys are exhausted, the security of the communication can be easily broken by using quantum computers. The control signals sent from the MGCC to the LC can thus be intercepted and falsified by an adversary. The impact of a malicious control signal on the NMGs system is illustrated in FIG.10, where the real power reference of the P-Q control for the battery in MG A is changed from 0 to -6 MW at time t = 16 s during the islanded mode. It can be observed that 1) the voltage’s magnitude decreases, 2) the frequency also decreases, and 3) at time t = 59 s, the system collapses. It is thus of great importance to have enough key bits in the KP. Effectiveness of TLKPS in Single-Attack Scenario [00100] There is now depicted a comparison of results of the numbers of bits in KPAA, KPAB and KPAC with and without TLKPS when only the quantum channel between MG A and MG C is attacked. In particular, FIG.11A shows a comparison of results of different KPs’ sizes without TLKPS; and FIG.11B shows a comparison of results of different KPs’ sizes with TLKPS. The noise for the quantum channel between MG A and MG C is set at 8 × 10 ⁻⁴ to simulate a strong attack, while the noises for other quantum channels are 5×10 ⁻⁴ . The distance between two MGs is set at 10 km, and the distance between each MGCC and its LC is 5 km. For the TLKPS strategy, the threshold is set at 10,000, meaning that once the number of bits in any KP is below 10,000, a given number of bits (which is set at 50,000) will be shared to that KP. It can be seen that: 1) as shown in FIG.11A, without TLKPS, there is a shortage of bits in KPAC while at the same time other KPs do not have the shortage issues; and 2) as shown in FIG.11B, with TLKPS, the shortage issue can be well solved; when the number of bits in KPAC is below 10,000, 50,000 bits are sent from KPAB to KPAC. Effectiveness of TLKPS in Multi-Attack Scenario [00101] There is further depicted a comparison of results of the numbers of bits in KPAA, KPCC and KPAC with and without TLKPS in a multi-attack scenario. In particular, FIG.12A shows a comparison of results of different KPs’ sizes without TLKPS; and FIG.12B shows a comparison of results of different KPs’ sizes with TLKPS. The noises for the quantum channel between MG A and MG B, and the quantum channel between MG A and MG C are both set at 8×10 ⁻⁴ to simulate strong attacks, while the noises for other quantum channels are 5×10 ⁻⁴ for weak attacks or no attack. The distance between MGCC A and LC A is set at 5 km, while the distance between MGCC C and LC C is 7 km for a slight difference in the numbers of bits in KPAA and KPCC. The distance between MG A and MG C is set at 9 km. The setting for the TLKPS strategy is the same as depicted in FIGs.11A, 11B. It can be seen that: 1) without TLKPS, in FIG.12A, there is a shortage of bits in KPAC; and 2) with TLKPS, as shown in FIG.12B, when the number of bits in KPAC is below 10,000, 50,000 bits are shared from either KPAA or KPCC to KPAC depending on which KP (KPAA or KPCC) has more bits; the shortage issue is well solved. Practical QKD Protocol [00102] Different protocols have been proposed to implement QKD such as the BB84, decoy-state, six-state, Ekert91, and BBM92. A practical decoy-state BB84 QKD protocol is chosed for its ability to tolerate high channel loss and to operate robustly even with today’s hardware. Its security and feasibility have been well-demonstrated by several experimental groups, and theoretical security analyses including the evaluation of concise and tight finite-key security bounds have been provided. [00103] The idea of this protocol is as follows: The information is encoded into qubits and then sent out by one party, commonly named Alice, using weak coherent laser pulses. With today’s technology, the production of a single qubit is not practical; instead, weak coherent laser pulses are used. However, these pulses contain, with non- zero probability, multiple qubit signals that would cause a break in security. To tackle this challenge, the decoy-state protocol varies the intensity of each laser pulse randomly using one of three intensities k ₁ , k ₂ and k ₃ , which are the intensities of the signal state, decoy state and vacuum state, respectively. Two bases X and Z are selected with probabilities p _x and 1 − p _x , respectively. Recall that these bases refer to the polarization setting of the qubit. The other party, named Bob, measures the qubits by randomly selecting bases from X and Z. If Alice and Bob choose the same basis, they share information since sending and receiving qubits in the same basis, as mentioned, leads to a deterministic outcome; otherwise, the iteration is discarded. By repeating this numerous times, the two parties share the referred to raw-key, which is partially correlated and partially secret. Error correction is then performed (leaking additional information to the adversary which must be taken into account) followed by privacy amplification, yielding a secret key of size ℓ. [00104] To integrate QKD systems into a real-time microgrid simulation testbed, a QKD simulator is implemented using Python that is capable of simulating QKD protocols. FIG.13 is a flow chart depiction of the QKD simulator 300 capable of simulating the decoy-state protocol. Note that this simulator is easily extensible for different QKD protocols. [00105] In this simulator, time is used as the indicator to determine whether a sufficient number of key signals have been sent by the laser for generating the secret key of size ℓ. In itializing the parameters at 302, at 305 there is let the current time be t _c , and the last calling time be t _p . Then, at 310, within the interval (t _c − t _p ), the number of signals that have been sent by the laser, N _t , can be obtained as where v _s is the speed of the laser sending signals, a constant value assumed in this study. [00106] The post measured signals received by Bob are temporarily stored in a classical “buffer”. When a sufficient block size of signals have been received, the post processing will start. Let the block size for post processing be ^ which is set by the users, and the number of signals needed to be sent before the post processing can start be N _r . Then, at 312, there is computed: [00107] where N _b' is the number of raw-ke y signals in the buffer , and R _c is the rate of correctly-received raw-key signals, i.e., the ratio of the number of correctly-received signals (leading to a useful raw key) and the number of signals actually sent. Specifically, R _c can be calculated as follows: [00108] where p _dk is the probability that a signal with intensity k is received by Bob. It can be expressed as [00109] where P _ap is the after-pulse probability. r _k is the expected detection rate (excluding after-pulse contributions) for intensity k, and can be calculated as follows: ^[00110] where P _dc is the dark count probability and η _Bob is Bob’s detection efficiency. η _tr is the transmittance that is related to the fiber length L as follows: [00111] where the fibers are assumed to have an attenuation coefficient of 0.2 dB/km. When the simulator is called, N _t and N _r are calculated and compared at 315. Based on the comparison result of N _t and N _r at 315, two cases exist as described below: Case 1 [00112] If N _t is smaller than N _r , the post processing will not start, and the value of t _c will be assigned to t _p . Note that t _c is continuously increasing. Meanwhile, a certain number of signals within the time interval (t _c − t _p ) will be added into the “buffer". Let n _X,k be the number of X signals received using intensity k. Then, of course, n _X , the size of the raw key in the “buffer" with the X basis, is simply the sum of all n _X,k over all the intensities used. Specifically, n _X,k can be updated at 320 as follows: [00113] where R _X,k is the ex pected transmission rate of signals for intensity . It can be expressed as [00114] Similarly, the number of Z signals received using intensity k, n _Z,k , can be updated at 320 as follows: [00115] where R _Z,k is the expected transmission rate of Z signals for intensity k, and can be expressed as ^[00116] The size of the raw key in the “buffer” with the Z basis, n _Z , is the sum of all n _X,k over all the intensities used. [00117] For one simulation, it is assumed a standard fiber channel and practical settings for devices. In this case, the probability of having a bit error for intensity k, b _k , is as follows: [00118] where e _mis is the error rate due to optical errors. Then, the number of erroneous bits in the Z basis for intensity k, n _{Zr ,k} , can be updated at 320 as follows: ^[00119] where (R _{Zr ,k} is the expected transmission error rate in the Z basis for intensity k, and can be expressed as [00120] When all the X, Z, and erroneous signals with all the intensities have been added, the simulator goes back to the “listening” mode at 325. As mentioned, t _p becomes t _c , and t _c continuously grows. Case 2 [00121] Returning back to 315, FIG.13, if it is determined that N _t is greater than or equal to N _r , post processing will start at 330. The simulator will then add all the X, Z, and erroneous signals with all the intensities into n _X,k , n _Z,k and n _{Zr ,k} , respectively. Specifically, n _X,k , n _Z,k and n _{Zr ,k} can be updated in the following way: [00122] After the post processing is completed, the key is established and can be used by Alice and Bob. The simulator simulates the process by calculating, at 335, the length ℓ of the extracted secret key that would be generated under the same conditions in practice. The length ℓ of the extracted secret key can be obtained as follows: ^[00123] where ℎ(x) = −xlog ₂ x − (1 − x)log ₂ (1 − x) is the binary entropy function. ξ _X,0 , ξ _X,1 , and Φ _x are the number of vacuum events, the number of single-photon events, and the phase error rate of the single-photon events in the raw key with the X basis, respectively. ε _c is the probability that the keys extracted by the two parties are not identical, and ε _s is the user-specified maximum failure probability. λ _ec specifies how much information is leaked during error correction. It is set to n _x η _ec ℎ(Φ _x ), where η _ec is the error-correction efficiency. [00124] The above parameters cannot be directly observed; however, by using the decoy-state protocol, they can be bounded. Basically, ξ _X,0 satisfies [00125] where X _n is the probability that Alice sends a n-photon state. This value, using a weak-coherent laser, follows a Poisson distribution and is found to be: [00126] and [00127] The number of single-photon events in the raw key with the X basis, ξ _X,1 , satisfies [00128] Similarly, by using (16)-(19) with statistics from the basis Z, the number of vacuum events in Z _A , ξ _Z,0 , and the number of single-photon events in the raw key with the Z basis, ξ _Z,1 , can also be obtained. [00129] The phase error rate of the single-photon events in the raw key with the X basis, Φ _x , satisfies, [00130] where [00131] and δ _Z,1 is the nu mber of bit errors of the single-photon events in the raw key with the Z basis. It is given by [00132] where [00133] and } Here, m _Z,k is the number of error events in the ^ basis. [00134] In an embodiment, the initial values of the parameters from equations (1)-(23) are given in Table 1. Table 1: Initial values of the parameters in the QKD simulator [00135] In sum, this simulator simulates the probabilities of various events occurring such as multiple-photon emission, photons being lost in the channel, phase errors, and detector imperfections. The simulator assumes quantum signals are continually being sent from end-nodes building a raw-key pool. When the simulator is called, it determines how many signals could have been sent from the last call (based on the speed of the simulated laser source and detector dead times), what the user’s choices were for those signals (e.g., basis and intensity choices), and whether the receiver got a measurement outcome. If a sufficient number of signals have been sent, the error correction and privacy amplification results are simulated leading to the generation of a simulated secret key of the actual size that would be generated under these conditions in practice. These secret key bits are added to the corresponding key pool as shown at 340, FIG.13. Then, n _X,k , n _Z,k , n _{Zr ,k} values are reset at 345 and the simulator goes back to the “listening” mode at 350 and t _p becomes t _c . The number of signals that have been sent by the laser, N _t is then updated at 355 and the process returns to 315, FIG.13. [00136] Note that this QKD simulator is able to flexibly alter QKD parameters for simulating different scenarios, e.g., with different fiber lengths and noise levels. The simulator is also easily extensible for different QKD protocols and quantum channels. With a different QKD protocol, the steps 312, 320, 330, 335 in FIG.13 need to be changed correspondingly. [00137] ]QKD is one of the most secure and practical instances of quantum cryptography. Specifically, using QKD provides the following benefits for microgrid: - Keys generated by QKD are almost impossible to steal even in the face of an adversary with infinite supplies of time and processing power, because by encoding a classical bit using a randomly-chosen basis, an adversary unaware of the basis choice can never be truly certain of the information being transmitted; - QKD is particularly well-suited to produce a long random key, which makes the OTP more realistic in practice. When QKD is combined with OTPs, both the key generation and encryption are unconditionally secure. - A QKD-enabled microgrid is able to detect the presence of an eavesdropper trying to gain knowledge of the keys, whereas existing communication systems without this ability will inevitably require extra detection mechanisms. This is because any attempt to learn keys causes noise in the quantum channel which can be detected by users. - QKD systems have the advantage of automatically generating provably secure keys over those manually distributing keys. This is needed in microgrid to satisfy various continuous data transmission requirements. [00138] In a further embodiment, the QKD networked microgrid systems further incorporate real SDN switches (i.e., four Pica8 SDN switches) with attendant practical SDN functionalities to improve the resilience of the QKD-enabled microgrids. [00139] In addition, an enhanced QKD simulator that can not only demonstrate the number of key bits generated each time by QKD, but also store the number of data that would need to be transmitted classically to get the real QKD system to work. The QKD- and SDN-Enabled Microgrid Architecture [00140] The architecture of the QKD- and SDN-enabled microgrid 400 is illustrated in FIG.14. The architecture consists of four layers, namely application layer 410, SDN control layer 420, data layer 430, and physical layer 440. In contrast to a traditional switch where the control and data layers are bounded together, an SDN switch separates its control and data layers where the control rules are developed in a separate SDN controller, making the SDN switch a simple forwarding switch. This setup offers a more flexible environment to manage the control logic including either modifying the existing control rules or developing new ones. [00141] A QKD system consists of a quantum channel and a classical one, where the quantum channel is used to transfer quantum bits (qubits) from one party to the other and the classical channel is used for tasks including post-processing and normal data transmission. In this architecture, the classical channel for each QKD system goes through the SDN network, i.e., every classical packet sent from one party to the other is managed by SDN, no matter it is for the purpose of postprocessing or normal data transmission. SDN Applications for Improving System Resilience [00142] Three SDN functionalities are implemented in the embodiment shown in FIG. 14. Different with other applications, they are designed particularly for the sake of improving the resilience of QKD-enabled microgrids. They are also practical solutions to promote the adoption of QKD in microgrid contexts. [00143] 1) Dynamic Routing 412, FIG.14: In QKD protocols such as the BB84 protocol, qubits are transferred from one party to the other over the quantum channel for generating “raw keys”, and postprocessing steps including the error correction and privacy amplification, are later conducted over the classical channel to distill final keys. This results in that more data packets are injected into the communication network. If more QKD systems are installed in a microgrid, classical channels are likely to be crowded, potentially affecting the normal data transmission. In this embodiment, an SDN-based dynamic routing method is developed to tackle this issue. Specifically, an SDN switch, based on the control rules developed in the SDN controller, will forward the data via a different route under certain scenarios, e.g., when there is a link failure or the rate of packets in a link is above a threshold. The control rules can be flexibly modified in the SDN controller. [00144] 2) Rate Limitation 414, FIG.14: The key generation speed of a QKD system can be affected by a variety of parameters such as the distance between two communicating parties, and the noise level on the quantum channel. Meanwhile, the key consumption speed is determined by the frequency of the normal data transmission. In a QKD-enabled microgrid with multiple QKD systems installed, it is likely that some QKD systems do not have enough keys while others have too much. An SDN- based rate limitation method is developed to address this issue. Specifically, a higher rate of packets is assigned to a QKD system that has a lower ratio of key generation speed and key consumption speed. This rate limitation function also works in other scenarios such as prioritization of those relatively-critical communications. The configuration can be dynamically changed over time within the SDN controller. [00145] 3) Firewall Implementation 416, FIG.14: Implementing firewalls in QKD- enabled microgrids is of great importance as the compromised data packets injected into either the QKD postprocessing or normal data transmission can cause problems. Unlike a traditional switch that typically does not have firewalls installed, an SDN switch can implement firewalls by developing control rules in the SDN controller. For instance, it can block all the traffics outside the local network, only allow packets from certain areas, or separate the data paths for the QKD post-processing and normal data transmission. The network security can thus be greatly enhanced and the performance of QKD-enabled microgrids can also be improved. SDN-enabled communication scheme [00146] Each microgrid has its own information such as the number of KPs it connects and the number of bits in each KP. It is, however, typically unconscious of the information owned by other microgrids. The SDN controller is thus established to manage the network by collecting information from each microgrid and providing the optimal decision unattainable by a single microgrid. In this study, SDAPP and TLKPS are enabled by SDN to mitigate DoS attacks under various circumstances. Specifically, the SDN controller has the following functions.1) It monitors the information of KPs including the number of KPs each MGCC possesses and symbols indicating whether each KP is willing to share bits for other KPs. It updates the information periodically. 2) If faced with a DoS attack, it determines which case it is and tells corresponding MGCCs which layer of the TLKPS strategy should be implemented.3) It provides parameters modification for each KP enabling a resilient, flexible, and economical NMGs system. [00147] In an embodiment, as the TLKPS strategy is only required when the number of bits in a KP is lower than a threshold Th, an event triggered communication scheme is established to reduce the communication bandwidth while still maintaining the system resiliency. KPs Monitoring [00148] In view of FIG.14, the SDN controller 420 is a logically centralized network controller that has access to all the SDN switches. It can communicate with all the MGCCs to collect KPs’ information. In the presented scheme, the SDN controller periodically sends requests to all the MGCCs. Once receiving a request, each MGCC sends corresponding information to the SDN controller. It is thus important for the SDN controller to identify each MGCC and corresponding local controllers. Using the IP protocol as an example, each MGCC or local controller has a unique IP address. The information sent from each MGCC to the SDN controller includes the following.1) IP addresses of all the local controllers that have established KPs with the MGCC. By knowing the local controllers’ IP addresses, the SDN controller not only obtains the number of KPs inside each microgrid, but also identifies those KPs.2) IP addresses of all the neighboring MGCCs that have established KPs with the MGCC. Similarly, the SDN controller obtains the number of KPs the MGCC connects outside the microgrid and identifies those KPs. Importantly, the SDN controller obtains a global overview of the KPs, with which it can determine if there is an alternative QKD path between two microgrids.3) A symbol (i.e., 0 or 1) for each KP indicating whether the MGCC is willing to share bits from this KP to other KPs at this moment. With this information, the SDN controller determines which KPs should be utilized to share bits in TLKPS. Compared with sending the number of bits in each KP, the confidentiality is improved. [00149] Once the SDN controller receives the above information, it updates the lookup tables 450, i.e., T1–T4 as shown in FIG.15. Specifically, tables T1 and T2 store IP addresses of local controllers and neighboring MGCCs that have established KPs with each MGCC, respectively. Tables T3 and T4 store the binary bits for KPs established inside each microgrid and between two microgrids, respectively. “1” indicates that the KP is willing to share bits for other KPs, and “0” means the KP refuses to share bits for other KPs. These tables will be checked when an event occurs and a request from any MGCC is received by the SDN controller. Event-Triggered Communication [00150] FIG.16 illustrates a logic diagram 475 of the event detection. To reduce the network bandwidth consumption (corresponding to the achieved throughput, i.e., the average rate of successful data transfer through a communication path), an event- triggered communication scheme is developed. E1 and E2 are two events defined in this scheme where event E1482 refers to the bit-sharing request from any MGCC to the SDN controller and event E2484 is the request clearance after bit sharing is completed. These events 482, 484 are detected by each MGCC. [00151] With more particularity, an E1 event 482 is triggered when the number of bits in a KP between two microgrids (i.e., Ni j) is detected to be lower than the threshold Th. Note that if the KP between any MGCC and a local controller lacks bits, the MGCC can implement the second layer of TLKPS directly because it has control of all the KPs surrounding itself. E2 event 484 is triggered only after E1 is triggered and when the given number (i.e., Ns) of bits have been shared to the KP. This detection sequence can be achieved by setting a flag 485 which is initialized at zero. [00152] When an E1 event is triggered, the MGCC sends the E1 request including its own IP address and the IP address of the other MGCC (with which the KP is established) to the SDN controller. Assume the index numbers of the two MGCCs are i and j, respectively. Upon receiving the request, the SDN controller checks T2 to determine whether there are any MGCCs that have established KPs with both MGCCs i and j. The procedures of the SDN controller for the E1 event are shown in FIG.17, where Nt refers to the total number of microgrids. [00153] FIG.17 shows a flow chart of a method 500 for the SDN controller for the E1 event. [00154] In response to receiving an E1 event, a check is made at look-up table T2 to determine at 505 whether both KP _ik and KP _jk exists. If there exists one MGCC k (checked in look-up table T2) and, as determined at 510, if the bits for both Nik and Njk are 1 (checked in look-up table T4), the SDN controller sends control signals to MGCCs i, j, and k to implement the first layer of TLKPS and the SDAPP at 515. Otherwise, returning to 505, if both KP _ik and KP _jk do not exist, the SDN controller checks T3 to select a KP from all KPs within MGs i and j that are willing to share keys and obtains an index number of the KP at 525. With the index number of the selected KP, the SDN controller checks T1 to obtain the local controller’s IP address at 530, and sends it to MGCCs i and j to implement the second layer of TLKPS and the SDAPP at 535, FIG.17. [00155] It is noted that the SDAPP is implemented not only for attacked KPs but also for KPs that will share bits to attacked KPs. When an E2 event is triggered, the SDN controller sends control signals to corresponding MGCCs to finish the sharing. Effectiveness of SDN-Enabled Communication [00156] The SDN-enabled event-triggered scheme is effective as illustrated in the following example taken in view of FIG.18. Specifically, the SDN controller receives 10 data packets from each MGCC per second to update the information. When an E1 event occurs, the speed for the E1 packets transmission from the MGCC to the SDN controller is set at 100 packets/s. At time t = 20 s, the number of bits in KP ₂ ¹ is below the threshold and E1 packets are sent from MGCC 2 to the SDN controller. At time t = 55 s, both KP ₂ ¹ and KP ₄ ¹ lack bits and E1 packets are sent from MGCCs 2 and 4 to the SDN controller. When an E1 packet is received by the SDN controller, the TLKPS is implemented and is completed in 1s. The data packets received by the SDN controller are monitored using Wireshark, and the results are illustrated in FIG.18. [00157] It can be observed from FIG.18 that the throughput increases to 16.2 packets/100 ms from 20 to 21 s, and 26.1 packets/100 ms from 55 to 56 s, signaling that the SDN controller has received the packets during E1 events. Compared with continuous data transmissions, this scheme requires a shorter period, greatly reducing the usage of communication bandwidth. Enhanced QKD simulator [00158] In addition to the capability of demonstrating the number of key bits generated each time by QKD (in the QKD simulator), an enhanced QKD simulator (QKDS+) is provided with a new feature, i.e., storing the amount of data that would need to be transmitted classically to get the real QKD system to work. Simulating the amount of classical data in QKD is vital to perform an accurate study and to determine how best resources should be distributed in microgrids. [00159] QKDS+ is also developed in Python. Its procedures are given in the method 600 depicted in FIG.19, where the decoy-state BB84 QKD protocol is adopted. Note that other QKD protocols can also be utilized with similar principles. Among various QKD protocols, the decoy-state BB84 QKD protocol is one of the most widely used schemes due to its capability of tolerating high channel loss and operating robustly. The basic idea of this QKDS+ protocol 600 is as follows: A transmitter, commonly named Alice, encodes information into qubits, and sends qubits to a receiver, commonly named Bob, through a quantum channel, i.e., a fiber. Weak coherent laser pulses are commonly utilized to prepare qubits. The intensity of each laser pulse varies randomly from three intensities ξ ₁ , ξ ₂ and ξ ₃ , i.e., the intensity of the signal state, decoy state, and vacuum state, respectively. Alice randomly selects a basis from two bases (denoted as X and Z) with a certain probability (i.e., p _x for basis X and 1− p _x for basis Z), to encode the information. When Bob receives the qubits, he also randomly selects a basis from X and Z (with a probability p _x for basis X and 1− p _x for basis Z) to measure the state of each qubit. For each qubit, if the same basis is selected by the two parties, the result measured by Bob will be the same with that prepared by Alice; otherwise, the result will be discarded. The two parties share a so-called raw key (partially correlated and partially secret) after repeating this numerous times. Post-processing procedures including the error correction and privacy amplification are then performed, over a classical channel, to distill a final secret key of size ℓ. [00160] In the QKD simulator of FIG.13 there is used time as an indicator to determine how many key bits have been generated at any moment. In QKDS+ of FIG. 19, two new variables are added, denoted as n _A (referring to the number of classical bits that need to be transmitted from Alice) and n _B (referring to the number of classical bits that need to be transmitted from Bob). Note that Alice does a lot more data transmitting than Bob. The numbers of required classical bits transmitted from Alice and Bob can be summarized as follows: - Alice needs to transmit her basis choices to Bob (1 bit per signal). Note that after Alice sends her basis choices to Bob, Bob will check: is this the same basis and did I get a signal (i.e., no vacuum)? If “yes” to both, Bob will transmit a “1” to Alice; otherwise, transmit a “0”. If Alice gets a “1” from Bob, she knows their basis choices are the same and that Bob did not get a vacuum. - Alice needs to transmit intensity choices (log ₂ 3 bits per signal since there are three intensities). - Bob needs to disclose whether he got a vacuum or not, together with his basis choices (1 bit per signal). - Alice and Bob need to determine errors in the Z basis. Thus, Alice and Bob need to disclose all their Z basis measurements (1 bit per signal for each party). - Alice needs to transmit error correction information, which requires γ _ec bits (γ _ec specifies how much information is leaked during error correction. - Alice needs to transmit a hash of the key to verify the correctness. This requires log ₂ ( ¹ / ε _c ) bits, where ] ε _c is the probability that the keys extracted by the two parties are not identical. - Finally, Alice needs to send privacy amplification data to Bob, which requires (size of raw key + size of final secret key - 1) bits. Formulations of QKDS+ [00161] As shown at 605, FIG.19, let ε _c be the current time input, and t _d be the last calling time. Then, at 610, within the interval (t _c − t _d ), the number of qubits that are transmitted from Alice to Bob, N _c , is as follows: [00162] where v _q is the frequency of sending qubits, e.g., 4 × 10 ⁷ bits/s. For each qubit, if Alice and Bob selected the same basis and the result measured by Bob is not vacuum (contributing to the raw-key), the result will be stored in a “buffer”. In the decoy-state BB84 QKD protocol, the post processing will only start after a sufficient number (denoted as B, a user-specified value) of X-basis raw-key signals have been stored in the “buffer”. Then, the number of qubits needed to be sent before the post processing can start (denoted as N _b ) can be computed at 615, FIG.19 as follows: [00163] where n _x is the number of existing X-basis raw-key signals in the “buffer”, and a _x is the ratio of the number of correctly received X-basis raw-key signals and the total number of signals actually sent, and can be obtained as follows: [00164] where ^s is the probability that a qubit is prepared with the intensity ξ (i.e., ξ ₁ , ξ ₂ , or ξ ₃ ), and p _dξ is the probability that a qubit is received with the intensity ξ. p _dξ can be obtained as follows: [00165] where p _ap is the after-pulse probability, i.e., 4 × 10 ^-2 in an example. r _ξ is the expected detection rate for intensity P, and can be expressed as [00166] where p _dc is the dark count probability, i.e., 6 × 10 ^-7 in this study, η _Bob is the detection efficiency of the receiver, and η _tr is the transmittance. With a fiber of length L (assuming the fiber has an attenuation coefficient of 0.2 dB/km in this study), η _tr can be obtained as follows: 1 _{0"A ^C/^A (29)} [00167 ] QKDS+ uses time as an indicator to determine both the number of keys generated and the amount of classical data required. At any time when QKDS+ is called, N _c and N _b are calculated and compared with each other. While N _c ≥ N _b , FOR- Do loop 620 is entered and the post processing will start leading to one or more pieces of final secret keys (each having a size of ℓ); otherwise, the post processing will not start. [00168] That is, if N _c < N _b , , the post processing will not start. The value of t _c is assigned to t _d , and a certain number of signals are added into the “buffer”. Let n _x,ξ be the number of X signals with the intensity P in the “buffer”. Then, the number of existing X-basis raw-key signals in the “buffer” (denoted as n _x , as mentioned), is the sum of all n _x,ξ over all the intensities. Specifically, n _x,ξ can be updated as follows: [00169] where α _x,ξ is the expected transmission rate of X signals with the intensity ξ, and can be obtained as follows: [00170] Similarly, the number of Z signals with the intensity ξ in the “buffer” (denoted as n _Z,ξ ), can be updated as follows: [00171] where a _z,ξ is the expected transmission rate of Z signals with the intensity ξ. It can be obtained as [00172] The number of existing Z-basis raw-key signals in the “buffer” (denoted as n _z ), is the sum of all n _z,ξ over all the intensities. The two newly-added variables, n _A (referring to the number of classical bits that need to be transmitted from Alice) and n _B (referring to the number of classical bits that need to be transmitted from Bob), are updated as follows: [00173] With a standard fiber and practical settings for devices, the probability of having a bit error for the intensity ξ, b _ξ , is [00174] where e _mis is the rate of the error in the fiber, caused by natural noises or an adversary attack. The number of erroneous Z-basis bits for the intensity ξ, n _{z r,ξ} , can be updated as [00175] where a _{zr ,ξ} is the expected transmission error rate in the Z basis with the intensity ξ. It can be obtained as follows: [00176] After all the X, Z, n _A , n _B , and erroneous signals with all the intensities have been updated from (30)-(37), QKDS+ goes back to the “listening” mode. Note that t _c continuously grows. [00177] Referring to FOR-DO loop 620, while N _c ≥ N _b : [00178] In this case, the post-processing will start. Similarly, n _x,ξ , n _z,ξ , n _A , n _B , and n _{zr ,ξ} are updated as follows: [00179] After each post processing is completed, a final secret key of size ℓ is established. Specifically, ℓ can be calculated at 635, FIG.19, as follows: [00180] where ℎ(j) is the binary entropy function, i.e., ℎ(j) = −jlog ₂ j − (1 − j)log ₂ (1 − j). n _x,0 , n _x,1 , and β _x are the number of vacuum X signals, the number of single-photon X signals, and the phase error rate of the single-photon X signals in the "buffer”, respectively. ε _c is the probability that the keys extracted by Alice and Bob are not identical, and ε _s is the maximum failure probability, a user-defined value. γ _ec specifies how much information is leaked during error correction, and can be expressed as n _x η _ec ℎ(β _x ), where η _ec is the efficiency of the error correction. The above parameters can be bounded. Basically, n _x,0 satisfies [00181] where λ _n is the probability of sending a n-photon signal, which follows a Poisson distribution as follows: with ^ ^± is expressed as follows: In (39),n _{x ,1} satisfies [00182] Similarly, the number of vacuum Z-basis signals in the “buffer”, n _z,0 , and the number of single-photon Z-basis signals in the “buffer”, n _z,1 , can also be obtained by using (40)-(43) with statistics from the basis ^. [00183] In (39), β _x satisfies where [00184] and δ _z,1 is the number of bit errors of the single-photon Z-basis signals in the “buffer”, and is expressed as where [00185] and } Here, } is the number of erroneous events in the Z basis. [00186] After the post-processing is completed, n _A and n _B can be updated at 640. FIG. 19 as follows: [00187] The initial values of the parameters from (23)-(48) are shown in Table 2. SDN-Enabled Real-Time Testing Environment [00188] In a further embodiment, there is provided a QKD- and SDN-enabled microgrid testbed using RTDS, QKDS+, and real SDN switches. Unlike other power system testbeds, this system has its unique feature, i.e., the quantum key generation and key consumption are integrated in a microgrid context where the generation speed is determined by a complete QKD algorithm and the consumption speed is affected by the real data transmission managed by the SDN controller over real SDN switches. This design presents a realistic cyber-physical test environment incorporating both SDN and QKD features. [00189] A further QKD- and SDN-enabled microgrid real-time test environment is shown in FIG.20 consisting of four computers (PCs), a traditional L2 switch, four Pica8 SDN switches, GTNET× 2 cards, and the RTDS hardware. PC 1, which is connected to four SDN switches using Ethernet cables and a traditional switch, functions as the SDN controller. PC 2 is used to not only serve as the microgrid control center (MGCC), but also run the RSCAD, namely the software used to compile the microgrid model and send the model to the RTDS hardware for real-time simulation. The GTNET× 2 cards, installed within the GTNET chassis, can either transfer data from the RTDS to external devices, or in a reverse way. [00190] FIG.21 depicts a hardware connection 650 and an accompanying flow chart 650 depict the MGCC processing logic. As shown in FIG.21, two data paths are created with four Pica8 SDN switches. For Path 1, each packet goes from Switch 1, through Switch 2, to Switch 4. For Path 2, each packet flows from Switch 1, through Switch 3, to Switch 4. For each SDN switch, the control logic is developed separately using the field “datapath.id” (as each SDN switch has a unique dpid). To find the dpid of an SDN switch, the following command can be applied via Putty: “ovs-ofctl show br0”. Two PCs (i.e., PCs 3 and 4 in FIG.20) with Wireshark installed are used to capture the traffic flowing through the two paths, respectively. The following command can be utilized to add two flows in an SDN switch from Port 1 to Ports 2 and 4: “ovs- ofctl add-flow br0 in_port=port1, actions=port2, port4”. To verify the flows are correctly added, the following command can be utilized: “ovs-ofctl dump-flows br0”. [00191] FIG.22 shows a further embodiment of a microgrid model 680 utilized in an embodiment. Microgrid model 680 contains a 1.74 MVA photovoltaic (PV) system, a 5.5 MVA diesel generator, a 2 MW doubly-fed induction generator wind turbine system, a battery, and 7 power loads at different buses. A P-Q controller is designed to regulate the output power of the battery, the value of which is determined by the real and reactive power references transmitted from the MGCC. [00192] Referring back to FIG.21, the method 675 implemented as the MGCC works as follows: The QKDS+ quantum key distribution method continuously generates key bits and stores them into a key pool. Meanwhile, it listens to the data packets sent from the RTDS. When a packet is received, it consumes a certain number of key bits in the key pool, and then sends corresponding control signals to the RTDS. [00193] For the microgrid model and hardware connection of the testbed depicted in FIG.22, experimental results are provided including: 1) test on QKD, 2) test on dynamic routing, 3) test on rate limitation, and 4) test on firewall implementation. Case 1: Test on QKD [00194] The QKD performance is evaluated with this testbed. Specifically, a time- varying load with a magnitude of 2 MW and a frequency of 0.05 Hz is added to Load 2 to model the dynamic characteristics of loads. The value of the varying Load 2 is continuously sent from the RTDS to the MGCC through a GTNET× 2 card and the SDN network, with a frequency of 80 packets/s. [00195] When the MGCC receives each packet from the RTDS, it forwards the value of the received data, which functions as the updated real power reference, to the Battery’s P-Q controller. The value of the reactive power reference is kept at 0. Meanwhile, the MGCC consumes 64 bits from the key pool for modeling the encryption process. Note that key bits are continuously generated by QKDS+, and are stored into a key pool. In this case, for the QKDS+, the fiber length L is set at 5 km, 10 km, and 20 km, respectively. Other parameters are the same as given in Table 2. [00196] The number of key bits in the key pool and the numbers of classical bits generated from Alice and Bob are illustrated in FIG.23. It can be observed that: With a fixed QKD configuration, at regular intervals, a given number of key bits are generated by QKDS+; meanwhile, key bits are continuously consumed in the key pool (see FIG. 23A which depicts: QKD performance with different fiber lengths and the number of key bits). A larger fiber length leads to a lower key generation speed (see FIG.23A), which is reasonable due to the higher loss in the quantum channel. For a single QKD system, a great number of classical bits are generated from Alice and Bob (see FIG. 23B which depicts: QKD performance with different fiber lengths and the numbers of classical bits generated from Alice and Bob), which inevitably makes the traffic more crowded. The number of classical bits generated from Alice is more than twice as large as that from Bob (see FIG.23B); and changing the fiber length only has a little impact on the numbers of classical bits required from Alice and Bob, and its impact on Alice is slightly larger than that on Bob. Case 2: Test on Dynamic Routing [00197] A dynamic routing function has been implemented in this case. With the dynamic routing, when one classical data path is under attack, has a failure, or is too crowded, another path can be used in real time, which enhances the resilience of the QKD-enabled microgrids. Specifically, in this case, the initial system configuration is the same with that in FIG.23A with the 20 km fiber length used. At around time t =43s, another type of packet with a specific source MAC address is sent from the RTDS to SDN Switch 1 (this is achieved by using another GTNET× 2 card), which then forwards the packet to the SDN controller. The SDN controller, based on the control rules developed, removes the existing flows for Path 1 and adds new ones for Path 2 (see FIG.21 for Paths 1 and 2). [00198] FIGs.24A and 24B illustrate the test results. Two computers with Wireshark installed (see FIGs.14 and 20) are used to capture packets on the two paths. It can be seen that, the dynamic routing has been successfully achieved (see FIG.24B), while the key consumption process (reflecting the normal data transmission) is not affected (see FIG.24A), i.e., the slope of the line 700 in FIG.24A remains the same from 42s to 44s. Case 3: Test on Rate Limitation [00199] Unlike a traditional switch, the Pica8 SDN switch is capable of flexibly configuring the rate limitation function by applying the following command: “ovs-vsctl set interface port ingress_policing_rate=value”. In this test case, the rate threshold for Port 1 of Pica8 Switch 1 is set at 50 kbps. To demonstrate the effect of rate limitation, the frequency of data transmission from the RTDS to the MGCC is set at a time- varying sinusoidal value with a magnitude of 100 packets/s and a frequency of 0.1 Hz. Other parameters are the same with those in FIGs.24A, 24B. [00200] FIGs.25A, 25B give the test results of rate limitation with number of stored key bits under rate limitation (FIG.25A), and the traffic captured with and without rate limitation (FIG.25B). It can be observed that: [00201] When the rate of traffic is below the limitation threshold (e.g., from 26s to 28s; see the line 710 in FIG.25B, the number of key bits in the key pool is sinusoidal (see the line 715 in FIG.25A from 26^ to 28^), which is reasonable, as the frequency of data transmission from the RTDS to the MGCC is set at sinusoidal. [00202] However, when the rate of traffic is above the limitation threshold (e.g., from 32^ to 34^; see the line 720 in FIG.25B), the speed of key consumption becomes almost constant (see the line 725 in FIG.25A from 32^ to 34^). Case 4: Test on Firewall Implementation [00203] In the case of implementing firewalls using SDN switches, two subcases are created: In the first subcase, the Pica8 switches are configured as traditional switches, with no firewalls installed. In the second subcase, only those packets with particular source and destination MAC addresses are allowed to flow through Pica8 switches. This is achieved by using the “match” field when adding flows. In both subcases, the MGCC sends control signals to the RTDS whenever a packet is received; meanwhile, another computer, which models the attacker and is connected to Pica8 Switch 4, keeps sending fake control signals (i.e., zero real power reference for the Battery) to the RTDS (with a frequency of 100 packets/s). Other configurations are the same with those in FIG.24. [00204] FIG.26A shows the system’s performance before and after a fake control signal is received. It can be observed that the system collapses in around 7 seconds. However, as shown in FIG.26B, when firewalls are installed inside the SDN switches, no packets with source MAC addresses other than the allowed ones can flow through SDN switches. [00205] An embodiment addresses the technical challenges impeding a wide adoption of QKD in power grids. One critical issue is the distance limitation, i.e., the key rate of QKD is reduced exponentially with the increase of the distance between two parties, which is especially undesirable in a large-scale power grid with high frequencies of data transmission. Another is that QKD is limited to point-to-point communications, which results in that, in a power grid with intensive communicating devices, the choice of using QKD merely becomes impractical. [00206] To overcome these limitations, an efficient way is to establish a quantum network. By interconnecting a number of quantum devices, a quantum network not only extends the communication distance greatly, but also provides a more flexible environment for plug-and-play communicating devices, maximally utilizing quantum resources. However, the topic of developing quantum networks is still silent in the community of power grids, and there are challenges. For instance, continuous data transmission in power grids makes key consumption in power grids faster than that in many other applications such as online banking. Therefore, while keys are sufficient in many other applications, it is easier to exhaust keys in power grids. In addition, a power grid has a dynamic environment, where the data transmission frequency can change dynamically, resulting in a variable key consumption rate. Without a quantum network- integrated power grid testbed, it is difficult to determine whether a certain topology and a certain configuration of a quantum network will meet the data transmission requirements in a dynamic power grid. Moreover, the distance between two communicating parties in power grids can be larger than the limits of existing QKD protocols. Noise levels on different quantum channels in a power grid can also be different and dynamically changing. Further, the placement of multiple communicating DERs can affect system performance and also needs to be investigated. [00207] Thus, in a further embodiment, there is established a quantum network-based power grid (QNetGrid) framework and a real-time, reliable, flexible, programmable, and cost-effective QNetGrid software testbed that contains repeater-based quantum communication, quantum routing, real software-defined networking (SDN) switches, and real-time NMGs operations. In particular, a quantum repeater and routing based quantum network simulator (QNSim) is established that can not only simulate the number of generated key bits and the routing process, but also interact with any real- time power grid simulator. Unlike other existing quantum network simulators that either do not support real-time simulation, fail to work for large-scale quantum networks, lack flexibility for multi-party communications, do not support routing, or are too complicated to implement, QNSim is easy to implement, allows for real-time simulation, is flexible to alter network parameters, and is easily extensible for different network topologies, protocols, numbers of repeaters, distances between neighboring nodes, and routing strategies. With both NMGs and quantum network features incorporated, the QNetGrid testbed provides a unique test environment for various quantum network research in NMGs. Specifically, there is provided: [00208] A quantum repeater and routing based quantum network simulator, QNSim, is developed. QNSim can not only simulate the number of generated key bits and the routing process, but also interact with any real-time power grid simulator. It is easy to implement, allows for real-time simulation, is flexible to alter network parameters, and is easily extensible for different network topologies, protocols, numbers of repeaters, distances between neighboring nodes, and routing strategies. [00209] Quantum repeaters with and without quantum memories are respectively simulated in QNSim, providing a great example to show that QNSim can be easily modified for different protocols. The quantum network performances with the two types of repeaters are compared using the QNetGrid testbed, and valuable insights are obtained. [00210] Different routing scenarios are investigated, such as with different DER routing sequences, node priorities, and DER locations. This shows the critical importance of the QNetGrid testbed, i.e., evaluating the system performance under different scenarios with great flexibility and providing valuable guidelines before constructing real quantum networks in power grids in practice. [00211] A real-time QNetGrid testbed is built in RTDS. Details including NMGs modeling and operations, control strategies, and integration of QNSim, RTDS hardware, and real SDN switches are described. QNetGrid presents a practical application of quantum networking in NMGs, and the QNetGrid testbed can be utilized as a benchmark for various quantum network research in NMGs. [00212] Various test cases are designed, and the experimental results produced with the QNetGrid testbed provide valuable insights to build quantum networks in power grids. Quantum Repeater-based Communication [00213] Distributing quantum resources over a long distance is a challenging task due to the transmission loss in the quantum channel, e.g., an optical fiber. The classical way of using amplifiers to boost signals will destroy signals’ quantum property due to the no-cloning theorem. A quantum approach to overcome this challenge is to use quantum repeaters.1) Qubits: A qubit is a bit with quantum properties. Unlike a classical bit that is either zero or one, a qubit can be in the superposition of both zero and one. Before measuring a qubit, its state is uncertain; after it is measured, the quantum property of the qubit is destroyed, meaning that the qubit becomes a classical bit. In other words, a qubit can be measured only once. Mathematically, a qubit state (|φ>) can be represented as follows: [00214] where |0> and |1> represent th e two bases of quantum states, and α and β are probability amplitudes (they can be complex numbers) with property |α| ² + |β| ² = 1. Entanglement [00215] Quantum entanglement is a physical phenomenon in which a group of qubits shares correlations. For instance, if two qubits are entangled, each qubit state is uncertain until it is measured; however, once one qubit state is determined, the other qubit state will also be determined. BSM [00216] Bell states are four specific maximally-entangled quantum states of two qubits. Suppose that there are two entangled qubits, A and B. The following four quantum states (|Φ ⁺ >, |Φ->, |Ψ ⁺ > and |Ψ->) are four Bell states: [00217] where |0> _A and |1> _A are two basis states for qubit A, |0> _B and |1> _B are two basis states for qubit B, and ⊗ denotes the tensor product. BSM (Bell State Measurement) is a two-qubit measurement that determines which Bell state among the four the two qubits are in. Quantum Repeaters [00218] FIG.27A depicts a quantum repeater-based communication and in particular, a quantum repeater; FIG.27B depicts a quantum repeater chain. In FIGs.27A, 27B, a node is a quantum repeater (including a node with only the measurement capability) or a communicating party. The distance between two quantum nodes is indicated as “d”. [00219] A quantum repeater consists of two sources (each generates two entangled qubits) and a BSM device. As illustrated in FIG.27A, qubits A and D are sent to two communicating parties, respectively, and qubits B and C are sent to the BSM device. If the measurement of qubits B and C succeeds, qubits A and D will be entangled together. In this way, the two communicating parties, which are separated in a distance larger than the one reached using a single source, have shared two entangled qubits. If multiple repeaters are used that form a chain of repeaters, the distance between two communicating parties can be further extended (see FIG.27B). Entanglement Swapping [00220] A single repeater works is demonstrated and can be generalized similarly to multiple repeaters. In this instance, one party, commonly named Alice, and the repeater share a Bell state of the form R ; similarly, the repeater and the other party, commonly named Bob, share a Bell state in the same form. The goal of the repeater is to perform a Bell swap, thus creating an entangled state between Alice and Bob, while leaving the repeater unentangled from the final system (and thus the repeater cannot learn any subsequent information that Alice and Bob may derive from their established shared state). For notation, the four Bell states are denoted as as Φ ₀ = [00221] The joint state shared among all three parties is then: [00222] Here, R ₁ and R ₂ are used to denote the two qubits that the repeater node holds, and, in the last line, the subspaces are permuted for clarity, putting the repeater’s qubits in the two registers left most and Alice and Bob’s qubits right most. Note that above no operation was performed; this is simply the joint state of the system following the establishment of entanglement between Alice and the repeater (register (R ₁ ), and the repeater (register (R ₂ ) and Bob. From this, the repeater will measure its (R ₁ (R ₂ system in the Bell basis resulting in outcome Φ _i with probability 1/4 (that is, the repeater will see one of the four Bell states with equal probability). Following this, Alice and Bob’s qubits collapse to the state Φ _i . The repeater will then broadcast to Alice and Bob its measurement outcome, allowing Bob to perform a local operation (either a bit flip or a phase flip, or both) to “correct” their shared joint state to the desired Bell state Φ ₀ . Importantly, the repeater is unentangled with Alice and Bob at this point. Furthermore, any deviation from the protocol (e.g., if the repeater is corrupted by an adversary) can be detected by Alice and Bob as their resulting state will not be a pure Bell state and so will create detectable noise in the subsequent ^ or ^ basis measurements performed by the QKD protocol. [00223] The E91 QKD protocol is one of the important applications of quantum entanglement. It allows two remote parties, Alice and Bob, to establish a secret key using the shared quantum entanglement. Its basic idea is as follows: [00224] Step 1: A series of pairs of entangled qubits is distributed to Alice and Bob, respectively. Photons are commonly used to implement qubits, and the polarization of each photon is utilized to encode a quantum state. Specifically, two polarizations, namely the diagonal polarization (denoted as the basis X) and the horizontal polarization (denoted as the basis Z) are considered. [00225] Step 2: For each pair, Alice and Bob independently randomly (with a certain probability) select a basis from X and Z to measure the received qubit, respectively. If the two parties select the same basis, the information will be transmitted deterministically; if different bases are selected, the measured results will be uncorrelated. [00226] Step 3: Alice and Bob publicly announce their selected bases. They keep the measured results for which the same bases are used and publicly announce the rest of the measured results, which are then used to detect the occurrence of a potential adversary. [00227] Step 4: Post-processing procedures, including error correction and privacy amplification, are performed on an authenticated classical channel, producing a secret key with information-theoretic security. [00228] While there has been recent research in establishing quantum communication to secure data transmission in power grids, most related efforts focus on QKD. However, in a power grid with intensive communicating devices, a quantum repeater and routing based quantum network, with which communicating devices can be flexibly plug-and play in the network, is more required. While existing quantum network simulators either do not support real-time simulation, fail to work for large- scale quantum networks, lack flexibility for multi-party communications, do not support routing, or are too complicated to implement, integrating these simulators into a real-time power system simulator may or may not be applicable and proper designs and analyzes must be performed. [00229] Thus, in a further aspect, there is provided a repeater and routing based quantum network simulator, QNSim, that is easy to implement, allows for real-time simulation, is flexible to alter network parameters, and is easily extensible for different network topologies, protocols, numbers of repeaters, distances between neighboring nodes, and routing strategies. QNetGrid Modeling [00230] FIG.28 illustrates a QNetGrid architecture 800. Architecture 800 consists of four layers, namely an application layer 810, a quantum network layer 820, a classical network layer 830, and a physical layer 840. In the physical layer, a control center, which is coordinating the whole system, can communicate with certain DERs where secret keys are generated through the quantum network. [00231] Letting N _d denote the number of DERs (or any grid components) that need to communicate with the control center through the quantum network, then, each DER (i.e., DER _i , where i = 1,2, ... , N _d ) shares a separate key pool (i.e., KP _i ) with the control center, where the keys are stored and, when necessary, extracted. For the quantum network, there is considered a grid topology consisting of N × N nodes, each connected to its neighboring nodes, as exemplified in FIGs.29A, 29B. In particular, an example of QNetGrid quantum network in FIG.29A depicts a quantum network of a 5 × 5 grid with FIG.29B depicting a quantum link connecting two quantum nodes and the intra-node entanglement; and FIG.29C depicting the installing of more links around the control center. Considering an N × N grid with uniform distances is a useful first step in analyzing the potential benefits of quantum networks for microgrids and also in discovering how to appropriately operate it (e.g, what routing protocols to use). In general quantum Internet research, grid topologies with uniform distances are often the first considered in order to develop the framework needed to successfully operate the system, and so this approach is kept here, as this is the first time quantum networks of this type have been applied to microgrid scenarios. [00232] Specifically, each node can be a user (i.e., the control center or a communicating DER), or a quantum repeater (including a node with only the measurement capability). To generate keys for KP _i , the control center and DER _i first select a path through a series of nodes and then perform the E91 QKD protocol using intermediate nodes on the path. Let n _i denote the total number of nodes (including the control center and DER _i ) in the established path for DER _i and the control center. Different route schedules can result in different values of n _i s (here, n _i s refers to the whole group of n ₁ , n ₂ , ..., and n _Nd ), leading to different QNetGrid performance. The hardware requirements for experimentally implementing a quantum network depend on the implementation and typically include new sources, detector devices, fiber channels, and quantum repeaters. Note that a classical network is still needed, both for quantum post-processing and classical data transmission. The QNSim [00233] FIG.30 depicts a QNSim algorithm 900 according to an embodiment that consists of two parts: an iterative part 902 for determining the values of n _i s and an iterative part 910 for calculating the number of key bits generated at any time for each key pool. Specifically, a certain routing protocol is first utilized to determine the path between each communicating DER and the control center. If a path is found, the total number of nodes on that path, namely the value of n _i , will be determined at 907. If a DER cannot find a route to the control center, it will not establish the quantum key generation, meaning that keys will not be generated and added to the key pool. The routing in a quantum network normally only permits that one quantum link is used for one QKD system at each moment. Thus, the routing algorithm in QNSim is designed in a way that once a quantum link between two nodes is used by one DER, it is removed for other DERs. The value of n _i is determined one by one from DER ₁ to DER _Nd . [00234] After determining the values of all n _i s, the simulator enters the “listening” mode. When secret keys are required to secure communication between DER _i and the control center, the simulator checks if there are enough keys in KP _i . If so, a certain number of key bits will be consumed from KP _i , and the corresponding control signals will be sent from the control center to the RTDS. If not, the keys will not be consumed and the control signals will not be sent. [00235] Meanwhile, key bits are continuously generated and stored in each key pool. For a discrete-variable QKD protocol such as the E91, key bits of a given length are generated over a certain time period. Let t _c be the current time and t _p,i be the last calling time for KP _i . Then, within the time interval, t _c − t _p,i , the number of qubits that have been sent from the source to DER _i , N _t,i , can be calculated at 912 as follows: [00236] where v _s is the average speed of the source sending qubits, i.e., 4 × 10 ⁶ bits/s in an example. This framework at the single-qubit level for quantum networks is applied to power grids. While 4 × 10 ⁶ bits/s are used in the example evaluations, other speeds may be evaluated using a general-purpose simulator and will cause the key generation rate to scale proportionally. [00237] In the E91 QKD protocol, two communicating parties independently randomly select a basis from X and Z to measure each received qubit. It is assumed each receiver has a single photon detector capable of distinguishing the four BB84 states. It is also assumed that these detectors can fail with a certain probability, which is simply characterized with a single parameter p _b,1 (in Eq. (51)). The dark count and efficiency of the detector can be absorbed into this parameter (these are not parameterized separately). For each measurement, if both parties select the same basis, the measured result will be kept; if they select different bases, the result will be discarded. Among the retained results, those measured with the X basis are used to distill final secret keys, and those with the Z basis are utilized for error correction purposes. [00238] The two communicating parties, i.e., the control center and DER _i , temporarily store the results measured with the X basis in an X-basis “buffer", and store the results measured with the Z basis in a Z-basis “buffer”. Let n _x,i be the number of X-basis signals already in the X-basis buffer, and n _z,i be the number of Z-basis signals already in the Z-basis buffer. [00239] For DER _i and the control center, when a sufficient number (denoted as B _i ) of X-basis signals have been stored in the X-basis buffer, post-processing procedures will start. Note that B _i is set by users. Let N _r,i be the number of qubits that need to be sent to DER _i before post-processing can start. Then, as computed at 915, FIG.30, [00240] where R _x,i is the expected transmission rate of the X signals for KP _i , i.e., the ratio of the number of signals (for which both parties selected the basis X) and the number of signals actually sent. Case 1: With Memoryless Quantum Repeaters [00241] When all quantum repeaters have no memory, for a signal to contribute to the final secret key, both parties should choose the basis X, the photon should be transmitted through the channel successfully, and all repeaters should successfully perform the bell measurement. Specifically, (R _x,i can be obtained as follows: [00242] where p _x is the probability that the X basis is selected (therefore, the probability that the Z basis is selected is 1 − p _x ). In an example embodiment, p _x is set at 0.8. Note that it is not necessary to make the selection of both bases equally probable. Basically, the exact bias does not affect the security as long as the bases are randomly selected and there are enough signals. Meanwhile, adding a bias can improve the efficiency of the QKD system, and its value is something to optimize over - the values chosen were a decent ‘rule of thumb’, but there may be more optimal values. In particular, different choices of bias can only change the simulated results obtained. η _t,i is the total transmittance in the repeater chain for KP _i , and is related to the length of each quantum link, L, and the number of quantum links in the path, n _i − 1, as follows: [0024 3] where an attenuation coefficient of 0.2 dB/km is assumed for fibers. p _b,i is the total probability that BSM is successful in the repeater chain for KP _i . As there are (n _i − 2) repeaters on the path, p _b,i can be expressed as follows: ^ _{ª"^ ' J = ^ ` , (53)} [00244] whe re p _r is the probability that a quantum repeater will succeed, representing the quality of the repeater. To be specific, if p _r is set to one, the repeater is assumed to be perfect, and if p _r is less than one, the repeater is non-ideal. [00245] After N _t,i and N _r,i are calculated from equations (49)-(53), they are compared with each other. If N _t,i is smaller than N _r,i , the number of X signals stored in the X- basis buffer will not be sufficient for post-processing to start. In this case, the value of t _c will be assigned to t _p,i . Note that t _c is continuously increasing. Meanwhile, a certain number of bits within the time interval (t _c − t _p,i ) will be added to X-basis and Z-basis buffers. Specifically, n _x,i and n _z,i can be updated as where R _z,i is the expected transmission rate of Z signals for KP _i , and can be expressed as [00246] When all the X and Z signals have been added, the simulator goes back to the “listening” mode. As mentioned above, t _p,i becomes t _c , and t _c grows continuously. [00247] However, if N _t,i is greater than or equal to N _r,i , post-processing will start as indicated as processing 920, FIG.30. The simulator will then add all the X and Z signals to n _x,i and n _z,i , respectively. Specifically, n _x,i and n _z,i can be updated as follows: [00248] After completion of the post-processing, a secret key of size ℓ _J is established for KP _i and can be used by DER _i and the control center. The simulator simulates the process by calculating the length of the extracted secret key, ℓ _i , that would be generated under the same conditions in practice. The length of the extracted secret key, ℓJ, can be obtained as follows: [00249] where ℎ(x) = −xlog ₂ x − (1 − x)log ₂ (1 − x) is the binary entropy function. e _i is the worst-case estimate of the error rate in the Z basis for KP _i , and can be represented as [00250] where e ₁ is the error rate in the Z basis (or the probability of a bit flip in one link), and m is the number of outcomes. Note that while loss correlates with the distance (see (52)), it is not necessarily true that noise correlates with the distance. This depends heavily on the optical implementation. Thus, a setting of 0.05 is used for e ₁ which is typical in certain fiber implementations. Other values may be simulated by a general-purpose simulator, though the key rate would simply scale appropriately. In an embodiment, ξ(n _z,i , m) can be represented as follows: where ∈ is a small number, i.e., 0.000001 in an example. [00251] In (57), leak _EC characterizes the imperfect error correction and can be represented as follows: [00252] And, Δ _i can be represented as follows: Case 2: With Memory-enha nced Quantum Repeaters [00253] In this case, there is presented the QNSim with memory-enhanced quantum repeaters as an example to show that the QNSim can be easily modified for different protocols. Specifically, with memory-enhanced quantum repeaters, only R _x,i and R _z,i (in equations (51) and (55), respectively) need to be adjusted properly. Procedures and other formulations do not need to be changed. In an embodiment, the nested purification protocol is adopted for the quantum repeater protocol. This protocol connects a string of (imperfect) entangled qubit pairs to create a single distant pair of high fidelity. It can tolerate general errors and work with a polynomial overhead in time and a logarithmic overhead in the number of qubits that need to be controlled locally. Note that other protocols for repeaters or QKD can also be utilized, while the principles are similar. [00254] In the nested purification protocol, the distance between two communicating parties (denoted as D) is divided into 2 ^N segments, each of length L = D/2 ^N , where L is the distance between two neighboring quantum nodes (as defined before) and N is the maximum nesting level, a natural number. Therefore, the number of repeaters between the two communicating parties is 2 ^N − 1. For DER _J and the control center, the maximum nesting level (denoted as N _i ) is therefore log ₂ (n _i + 1). (R _x,i can then be obtained as follows: [00255] where η _tr is the transmittance in the fiber between two neighboring quantum nodes and can be determined as follows: [00256] where an attenuation coefficient of 0.2 dB/km is assumed for fibers. Similarly, (R _z,i can be obtained as follows: [0025 7] In an embodiment, the initial values of the parameters from (49)-(64) are given in Table 3. Table 3: Initial Values of The Parameters in QNSim Quantum Routing for QNetGrid [00258] Without loss of generality, a typical shortest path routing protocol is utilized in QNSim to select a route for each communicating DER, that is, to determine the value of ni. Integrating a routing protocol into QNSim provides a more realistic test environment, and the routing process can also be observed in QNSim. A routing protocol is presented along with routing scenarios in QNetGrid. The Routing Protocol in QNSim [00259] In a quantum network, two neighboring nodes are connected through a quantum link, and each link is associated with a weight, representing the physical distance or the transmission delay of the link. The shortest path routing aims to find a route for two communicating nodes along the links such that the sum of link weights is minimum. For simplification, in an embodiment, the links are assumed to have the same weight, i.e., 1. Note that each link’s weight can be different and even dynamically changing in practice, while the routing principle remains the same. [00260] The shortest path routing in QNSim utilizes a distance vector to form a routing table for each node, which contains information including a list of reachable destinations, the total cost (i.e., the sum of total link weights) to each reachable destination, and the next neighboring node ID to reach there. Specifically, the protocol works as follows: [00261] Multiple rounds are involved. In the first round, each node only has its neighbors’ IDs and the costs involved. Each node then sends to each neighbor its routing table, which, in this case, contains its neighbors’ IDs, the total cost to each, and its own ID. When each node receives the information from a neighbor, it compares the information with that in its own routing table. Any new information will be inserted into the routing table. In every next round, each node sends its updated routing table to its neighbors, and when a node receives information, its routing table is further updated. Over time, each node finds the next neighbors to which it should reach and the total costs of all destinations. [00262] It is noted that each node only has its local information in the routing protocol in an embodiment. There are also some global routing protocols and other local routing protocols; but the routing principles are similar. [00263] In a further embodiment, when a route has been established for a pair of two communicating parties, it is not allowed to be used for other pairs of communicating parties. This is reasonable, as there exists a physical speed limit for transmitting signals over a quantum channel. If multiple pairs of communicating parties share the same quantum link, the signal transmission speed on that link for each pair of communicating parties will inevitably be reduced. In an embodiment, each quantum link is used only for one pair of communicating parties at each moment. Note that the system configuration can be updated at different times. This setting guarantees that a communicating device lacking keys will obtain the best key service, that is, the fastest key generation. Those communicating devices with enough key bits in their key pools may find longer routes without affecting their normal operations. QNetGrid Routing Scenarios [00264] In an embodiment, three critical factors can affect the overall routing performance in QNetGrid with multiple communicating DERs: 1) DER routing sequence, 2) node priority, and 3) DER location. The DER routing sequence is the sequence of DERs that select routes. The node priority is the sequence of route selection when there are multiple routes with the same minimum cost during the routing process. [00265] FIG.31 shows a Quantum routing for QNetGrid with FIG.31A depicting when there are two or more neighbors that can connect to the control center at the same minimum cost, the node priority is “a” to “y”, and the DER routing sequence is DER ₁ - DER ₂ -DER ₃ -DER ₄ ; FIG.31B depicting when the node priority is “a” to “y”, and the DER routing sequence is changed to DER ₁ -DER ₃ -DER ₄ -DER ₂ . [00266] FIG.31 gives two examples of routing results, where each node is assigned an ID, from “a” to “y”, respectively. In FIG.31A, the DER routing sequence is DER ₁ - DER ₂ -DER ₃ -DER ₄ , meaning DER ₁ first selects a route, and this is followed by DER ₂ , DER ₃ , and DER ₄ , respectively. The node priority is from “a” to “y”, which means that for each node, when there are two or more neighbors that can reach the control center with the same minimum cost, the selection priority is from “a” to “y”. With this node priority and the DER routing sequence, all DERs can find a route connecting to the control center. However, when the node priority remains the same and the DER routing sequence is changed to DER ₁ -DER ₃ -DER ₄ -DER ₂ , the overall routing performance becomes worse as illustrated in FIG.31B, where for DER ₂ , five quantum repeaters are included along the route, causing a longer communication distance between DER ₂ and the control center. In addition, the DER location plays a vital role in the overall QNetGrid routing performance. In an example, three DER placements in the quantum network are investigated, referred to as corner, diagonal, and distributed placements, as exemplified in FIGs.32A, 32B. In particular, FIG.32A depicts example three DER placements in QNetGrid including two example scenarios 1 and 2 (e.g., Corner and Diagonal) and FIG.32B shows a third example scenario (e.g., Distributed). Grid Model and Operation [00267] A communication-based six-microgrid NMGs system 1000 in the form of a one-line diagram of the system is depicted in FIG.33 to evaluate the performance of QNetGrid in different scenarios. The system 1000 contains six microgrids including ten DERs and eight power loads, and can operate in either grid-connected or islanded mode depending on whether the circuit breaker between buses 2 and 3 is closed or open. In an embodiment, it operates in the islanded mode. [00268] Specifically, all DERs use traditional droop control as the primary control strategy to maintain the system frequency and voltage. Among all the DERs, some DERs are only equipped with the droop controller, while some have a secondary controller, i.e., the power-sharing-based control strategy, as will be discussed later, above the droop controller. The DERs with droop and secondary controllers will communicate with the control center, whereas the DERs with only the droop controller will not. The number of communicating DERs can vary in different test scenarios. Let N _d be the number of communicating DERs (which is also the number of key pools as mentioned), and N _m be the number of DERs without communication. [00269] For DERs without communication, the reference frequency and output voltage of the j ^th DER inverter can be expressed as follows: where ω _r,j is the reference frequency of the j ^th DER inverter. v _rd,j and v _rq,j are the reference w-axis and Â-axis output voltages of the j ^th DER inverter, respectively. ω _0,j and v _od,j are the nominal set points of frequency and w-axis output voltage of the j ^th DER inverter, respectively. p _j and Q _j are the real and reactive output power of the j ^th DER inverter, respectively. K _P,j and K _Q,j are the frequency and voltage droop coefficients for the j ^th DER inverter, respectively. [00270] One rationale of this controller is to fine-tune the reference frequency and voltage by using the actual real and reactive power sharing from other communicating DERs. It uses information on the total real power generation of all communicating DERs (¿ _^>^ = ∑ ^# J _§ ^¨ ^ ¿ _J ) and the reactive power generation of all communicating DERs (Á _^>^ = ∑ _J§^ Á _J ), where P _i and Q _i are the real and reactive power generation of DER _i , respectively. When the power-sharing-based controller is added above the droop controller, the reference frequency and voltage of the DER _i inverter are given by [00271] where and ,J have the same meaning as in equation (65), respectively, except that they are for the i ^th DER inverter among communicating DERs. K _Ps,i and K _Qs,i are real and reactive power sharing gains of the DER _i inverter, respec tively, an d α _{P ,i} and α _Q,i are the coefficients with respect to the desired sharing of real and reactive power by DER _i , respectively. Specifically, there is obtained [00272] With the secondary controller, each com municating DER (e.g., DER _i ) periodically sends its P _i and Q _i to the control center. The control center updates P _tot and Q _tot using the information received from all communicating DERs, and sends αp,iP _tot and α _Q,i Q _tot to DER _i . When each communicating DER receives the data from ce frequency and voltage are updated according to (66). Some critical parameters of the system are given in Tables 4 and 5. Load ¿ (kW) Á (kVAR) Load ¿ (kW) Á (kVAR) ½ ^{¾,¼ ½À,¼ ½¾,J ½À,J ½ÀZ,J ½¾ J} The QNetGrid testbed [00273] The QNetGrid testbed 1100 is illustrated in FIG. 34. The QNetGrid testbed 1100 consists of a control center, four software-defined networking (SDN) white box switches, an SDN controller, a traditional switch (L2 switch), GTNETx2 cards, and RTDS hardware. The hardware connections on the testbed is shown in FIG. 35. Specifically, in the hardware connections 1200 of FIG. 35, the six-microgrid system is developed and compiled in RSCAD, which is designed to interact with the RTDS hardware 1210. The control center 1225 and RSCAD are running on the same server. In one embodiment, the entire network is managed using the real SDN network 1250, which allows for a programmable, reliable, and efficient network management environment. It allows for real-time packet monitoring and network configuration, and greatly improves the network performance compared to traditional network management. Four SDN switches 1260, managed by an SDN controller through a traditional switch and Ethernet cables, are used in this embodiment to form a realistic network environment. Each SDN switch 1260 has a number of ports used to connect to other SDN switches or other devices such as GTNETx 2 cards and servers.

[00274] In FIG. 35, the GTNETx 2 cards are utilized for RTDS hardware to communicate with external devices, such as the control center running on the remote server. In an embodiment, , each communicating DER has two GTNETx 2 cards 1270, 1275. One is used to send P _i and Q _i to the control center, and the other is used to receive α _{P ,i} P _tol and α _{Q ,1} Q _tol sent from the control center. Each GTNETx 2 card has a specific IP address, and GTNETx 2 cards that receive data from the control center are assigned different ports. Note that GTNETx 2 cards sending data to the control center do not need port information. The User Datagram Protocol (UDP) is utilized for communication in the testbed. The QNSim algorithm 900 of FIG. 30 is running within the control center. It continuously generates key bits and stores them in the corresponding key pools. When it receives P _i and Q _i from DER _i , a certain number of bits (e.g., 64 bits in this study) are consumed in KP _i . In this way, the key generation and consumption for each communicating DER are associated with the operation of the DER. Note that while different power grids have different conditions, such as topologies, operations, control paradigms, and information availability, the principles of QNetGrid can be extended to other systems, and only slight modifications are required. [00275] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. [00276] The described aspects and examples of the present disclosure are intended to be illustrative rather than restrictive, and are not intended to represent every aspect or example of the present disclosure. While the fundamental novel features of the disclosure as applied to various specific aspects thereof have been shown, described and pointed out, it will also be understood that various omissions, substitutions and changes in the form and details of the devices illustrated and in their operation, may be made by those skilled in the art without departing from the spirit of the disclosure. For example, it is expressly intended that all combinations of those elements and/or method steps which perform substantially the same function in substantially the same way to achieve the same results are within the scope of the disclosure. Moreover, it should be recognized that structures and/or elements and/or method steps shown and/or described in connection with any disclosed form or aspects of the disclosure may be incorporated in any other disclosed or described or suggested form or aspects as a general matter of design choice. Further, various modifications and variations can be made without departing from the spirit or scope of the disclosure as set forth in the following claims both literally and in equivalents recognized in law.