# Privacy-Preserving Data Aggregation with Dynamic Billing in Fog-Based Smart Grid
## 6 Comparison and Evaluation
### Computation Overhead
\begin{table}
\begin{tabular}{c c c c c} \hline \hline  & **SM Side** & **FN Side** & **AC Side** & **SP Side** \\ \hline [PERSON] et al.’s scheme [23] & \(T_{C-Paillier}+T_{E}\) & \((n+1)T_{B}+T_{E}\) & \(2T_{B}+T_{D-Paillier}\) & / \\ [PERSON] et al.’s scheme [27] & \(T_{C-ElGamal}+3T_{E}\) & \((n+1)T_{B}+T_{E}\) & / & \(2(n+1)T_{B}+T_{C-ElGamal}\) \\ Our scheme & \(T_{C-ElGamal}+T_{E}\) & \((n+1)T_{B}+T_{E}\) & \(2T_{B}+T_{C-ElGamal}+T_{E}\) & \(2T_{B}+T_{C-ElGamal}\) \\ \hline \hline \end{tabular}
\end{table} 
Table 3: Theoretical comparison of computational overhead. and time slots are set to \(n=10,t=10\), respectively. In the Registration phase, RKG runs the Key generation algorithm to generate keys for entities registered in the system. When \(n=10\), this process takes about 110 ms. In the Reports Generation phase, each SM first runs Encryption algorithm to encrypt data and then runs Signature algorithm to generate a signature. This process contains \((T_{C-ELGamal}+T_{E})\) and takes about 440 ms. After receiving reports from all SMs in the coverage area, FN runs the Batch verification algorithm to check the validity of these reports, and then runs the Signature algorithm to generate a signature after aggregating the valid ciphertexts. At this phase, PPDB has the same computational complexity (i.e., requires \((n+1)T_{B}+T_{E}\)) as in scheme [23; 27], which takes about 450 ms. In the Data Reading phase, AC first runs the pre-decryption algorithm to decrypt the report sent by the FN, and then the SP runs the decryption algorithm to obtain the final result. This process consists of \((4T_{B}+2T_{C-ELGamal}+T_{E})\) and takes about 60 ms. Our scheme also considers real-time-price-based billing and arbitration of disputed bills. When \(n=10\), \(t=10\), the Billing phase takes about 840 ms and the Arbitration phase about 65 ms. Upon receiving reports from all SMs in the coverage area, the FN can verify the reports by two different verification methods, which are single verification and batch verification, and our PPDB employs batch validation to verify all reports. The efficiency comparison result of the two different verification methods is shown in Figure 6, where the number of SMs is set to \(n=10,20,30,\cdots,100\). It can be seen that when the number of SMs is the same, the computation time required for batch verification is smaller than that required for single verification, and with the increase in \(n\), the time difference between batch verification and single verification will increase. When \(n=100\), single validation takes about \(0.6\times 10^{3}\) ms more than that for batch verification. The reasons for this are: when the number of SMs is \(n\), in addition to the less time-consuming multiplication and hash operations, single verification needs to perform \(2 nT_{B}\), while the batch verification only needs \((n+1)T_{B}\). When \(n\) is large (\(n\geq 60\)), the computation time required for multiplication and hash operations can be ignored; in this case, the computation time required for batch verification and single verification gradually shows a linear trend. Figure 5: Computation time in each phase (\(n=10\)). To further evaluate the performance of PPDB, in our simulations, we compared the computation time of [23; 27] and PPDB at each side in various cases (i.e., the number of SMs is set to \(n=10,20,30,\cdots,100\)). The experimental results are shown in Figure 7, where Figure 7a-d show the comparison of computation time of three schemes at the SM side, FN side, AC side and SP side, respectively. Although the computation time of PPDB is higher than that of scheme [23] at the SM side, in our scheme, each SM processes multi-dimensional data, while those in scheme [23] encrypts only one-dimensional data. From Figure 7b, it can be seen that the three schemes have almost the same computation time at the FN side because they have the same computational complexity at the FN side.