## 6 Evaluation of the Proposed Protocol
### Communication and Computational Complexity Evaluation
\begin{table}
\begin{tabular}{|c|c|c|} \hline \multicolumn{1}{|c|}{**Phase**} & \multicolumn{1}{c|}{**Protocol**} & \multicolumn{1}{c|}{**Total Expenditure (in bits)**} \\ \hline \multirow{5}{*}{Setupphase} & LEACH & \(32n^{2}+128n+96\) \\ \cline{2-3}  & SLEACH & \(32n^{2}+672n+640\) \\ \cline{2-3}  & SecLEACH & \(256n^{2}+416n+160\) \\ \cline{2-3}  & MS-LEACH & \(256n^{2}+816n+560\) \\ \cline{2-3}  & Ours & \(288n^{2}+2000n+1712\) \\ \hline \multirow{2}{*}{Data aggregation phase} & Ours & \(16n^{2}+1264n+368\) \\ \cline{2-3}  & ESPDA & \(656n^{2}+656n\) \\ \hline \end{tabular}
\end{table} 
Table 14: Comparison of intra-cluster radio transmission expenditure member nodes increases, the gap between the two schemes will increase. Because the data aggregation phase is executed more often than the setup phase, our scheme has merits compared to ESPDA. For the practical use of the LEACH-style routing schemes introduced in our paper, they need to add more steps in their data aggregation phase when they are combined with a specific data aggregation scheme such as ESPDA. This will introduce additional communication costs. By considering this fact, because the setup phase is relatively infrequent compared to the data aggregation phase, our protocol is comparable to the other LEACH-style routing schemes when they are combined with a specific data aggregation scheme. Another evaluation is for the amount of computation of cryptographic algorithms that takes place. Those cryptographic algorithms include hash function, symmetric encryption/decryption, MAC computation, digital signature generation and verification. We denote by \(C(\theta)\) the computation cost of operation \(\theta\). We consider hash operation cost and MAC computation equal since MAC computation employs a hash function, therefore we represent each of both as one unit of hash operation, \(h\). Since it is symmetric encryption/decryption, we consider both costs of operation equal and represent each of them as one unit of encryption operation, \(enc\). An exception is digital signature generation and verification. Both of them do not have equal computational costs, therefore we represent the signing operation as \(\sigma_{g}\) and its verification operation as \(\sigma_{v}\). As here we do not strict the proposed protocol to any specific digital signature algorithm, the computation cost can be expanded according to the chosen digital signature algorithm. Table 15 presents the cryptographic computation cost. Since we cannot tell exactly the execution time of each algorithm, we still can compare them by ordering them based on computation complexity. Let's say \(\widehat{m}\) is modular multiplication in \(\mathbb{Z}_{q}^{*}\), \(E\) is exponentiation in \(\mathbb{G}\) (equivalent to scalar multiplication in ECC), \(M\) is the multiplication in \(\mathbb{G}\) (equivalent to point addition in ECC) and, previously stated, \(C(h)\) is hash operation and \(C(enc)\) is symmetric encryption/decryption. We can sort the computational complexity of the algorithms as follows: \(E>M>\widehat{m}>C(enc)>C(h)\). In [24], [PERSON] _et al._ measured that their digital signing operation equals \(\widehat{m}\) and the signature verification equals to \(2E+M\). We can tell that the verification is more costly than their signing operation. From the comparison of computational complexity shown in Table 15, it is very obvious