# Privacy-Preserving Data Aggregation with Dynamic Billing in Fog-Based Smart Grid
## 6 Comparison and Evaluation
### Computation Overhead  
We first take a sub-region (with \(n\) SMs) as an example to analyse and compare the computational overhead at each side of the schemes of [23; 27] and PPDB theoretically. For the sake of fairness, our comparison focuses on the Reports Generation, Data Aggregation and Data Reading phases, which are present in all three schemes. Our analysis concentrates only on the most time-consuming operations, that is, encryption under the Paillier cryptosystem (denoted as \(T_{C-Paillier}\)), decryption under the Paillier cryptosystem (denoted as \(T_{D-Paillier}\)), encryption under the ElGamal cryptosystem (denoted as \(T_{C-ElGamal}\)), decryption under the ElGamal cryptosystem (denoted as \(T_{D-ElGamal}\)), bilinear pairing (denoted as \(T_{B}\)) and exponentiation operation (denoted as \(T_{E}\)). In our PPDB, each SM requires \(T_{C-ElGamal}\) to generate the ciphertext and another \(T_{E}\) for signature generation. After receiving the reports sent by \(n\) SMs, the FN first operates a batch verification algorithm to check the validity of all reports, which contains \((n+1)T_{B}\). In addition, the FN requires \(T_{E}\) to generate a signature. For AC, it first performs \(2T_{B}\) to verify the validity of the report sent by FN, \(T_{C-ElGamal}\) to pre-decrypt it and \(T_{E_{1}}\) to generate the signature. When it receives the report from AC, the SP first takes \(2T_{B}\) to verify it and then \(T_{D-ElGamal}\) to decrypt it. In summary, the total computation overheads at the SM side, FN side, AC side and SP side is \(T_{C-ElGamal}+T_{E}\), \((n+1)T_{B}+T_{E}\), \(2T_{B}+T_{C-ElGamal}+T_{E}\) and \(2T_{B}+T_{C-ElGamal}\), respectively. In [23], [PERSON] et al. only presented the dynamic billing process. For theoretical comparison, we supplement the electricity consumption statistics process for [23]. According to our supplement, in [23], each SM requires \(T_{C-Paillier}\) to generate ciphertext and \(T_{E}\) to generate signature. Hence, the total computational overhead at each SM side is \(T_{C-Paillier}+T_{E}\). The FN takes \((n+1)T_{B}+T_{E}\) to batch validate all reports received from the SMs and generates signatures. When receiving the report sent by the FN, AC performs \(2T_{B}\) to verify the validity of the report and \(T_{D-Paillier}\) to decrypt it. As a result, the total computation overhead at the AC side is \(2T_{B}+T_{D-Paillier}\). In [PERSON] et al. 's scheme [27], each SM requires \(T_{C-ElGamal}\) to generate the ciphertext and \(T_{E}\) to generate signatures. In addition, in the Data Reading phase, each SM needs to perform distributed decryption, which consists of \(2T_{E}\). In total, the computation overhead at each SM side is \(T_{C-ElGamal}+3T_{E}\). Same as scheme [23], in [27], the computation overhead at the FN side is \((n+1)T_{B}+T_{E}\). In the Data Reading, the SP needs \(2(n+1)T_{B}\) to verify signatures and \(T_{C-ElGamal}\) to decrypt the aggregated ciphertext. So, the total computation overhead at the SP side is \(2(n+1)T_{B}+T_{C-ElGamal}\). Theoretical comparison of computation overhead between our proposed PPDB and schemes [23; 27] is shown in Table 3. We can see that our scheme has low computation overhead at the SP side compared to the scheme [27]. We proceed to compare the computational overhead of the schemes [23; 27] and PPDB by conducting extensive experiments using the Java Pairing-Based Cryptography Library on a computer with a Microsoft Windows 11 operating system, an Intel Core i3-12100 CPU @ 3.30 GHz processor and 16 GB memory. Figure 5 presents the performance of our PPDB in the Registration, Reports Generation, Data Aggregation, Data Aggregation, Data Reading, Billing and Arbitration phases, where the number of SMs