## 5 Discussion  
Our scheme is compared in terms of storage overhead and communication overhead with the authentication scheme of [PERSON] et al. [15], which is treated as a benchmark scheme, and compared in term of communication overhead with the scheme introduced in [23] by [PERSON] et al. The authors of [15] presented a lightweight security solution including authentication using elliptic curve cryptography (ECC), hashing, and XOR operation for the publish-subscribe protocol based on fog computing. However, broker bridging, which allows a broker to act as a client and communicate with other brokers, was not addressed in Diro's scheme. We achieved a secure authentication level, including mutual authentication and \begin{table}
\begin{tabular}{c c} \hline \hline
**Entity** & **Storage Overhead** \\ \hline Client \(\rightarrow\) LB + AM & 1136 bits \\ LB + AM \(\rightarrow\) Client & 640 bits \\ LB \(\rightarrow\) AB + AM & 1136 bits \\ AB + AM \(\rightarrow\) LB & 640 bits \\ AB \(\rightarrow\) CB + AM & 1136 bits \\ CB + AM \(\rightarrow\) LB & 640 bits \\ \hline \hline \end{tabular}
\end{table} 
Table 6: Communication overhead. \begin{table}
\begin{tabular}{c c} \hline \hline
**Entity** & **Storage Overhead** \\ \hline Client & 512 bits \\ LB & 784 bits \\ AB & 784 bits \\ CB & 272 bits \\ \hline \hline \end{tabular}
\end{table} 
Table 5: Storage overhead for the client, LB, AB, and CB. resistance to attacks such as eavesdropping, impersonation, and replay attacks, and our scheme outperforms in terms of storage requirements and communication costs. In Diro's scheme, the results showed that the total storage requirements cost 7168 bits: 3328 bits for clients and 3840 bits for the fog broker (FB). The FB in Diro's scheme is equivalent to the cloud broker (CB) in our scheme because both brokers act only as a broker. The storage overhead in our scheme incurs 512 bits for clients and 272 bits for CB for a total of 784 bits. In other words, our scheme reduces the storage overhead to 89%. However, the functions of the FB in Diro's scheme differ from the FB in our scheme, which includes local and aggregation brokers, which act as clients and brokers. Although the FB in our scheme (local and aggregation brokers) incurs the storage overhead of the broker and client combined, they are almost five times lower than the FB in Diro's scheme. The storage requirements for the local broker and the aggregation broker cost 512 + 272 = 784 bits each. Figure 12 shows the storage overhead of clients and brokers for Diro's scheme and our scheme. On the other hand, the communication overhead of a client in our scheme costs 1136 bits, which is slightly greater than the client in Diro's scheme, which costs 1024 bits. Moreover, our scheme reduces the communication overhead for CB to the half with 640 bits. Taking into the consideration that the FB in Diro's scheme is equivalent to the CB in our scheme, since both brokers perform only the traditional broker functions and do not act as a client, the communication overhead of our scheme costs 1776 bits, while in Diro's scheme it costs 2304 bits. This means our scheme decreases communication overhead almost to 23%. However, there is a noticeable contrast between the FB in our scheme and Diro's scheme. The communication overhead for the FB in our scheme costs 1776 bits, whereas it costs 1280 bits in Diro's scheme. The increased number of bits in our scheme is attributable to the FB playing the role of the client and broker together, requiring each FB to have authentication parameters when it acts as a broker and different authentication parameters when it acts as a client, because each FB communicates with two different authentication managers. Figure 13 illustrates the difference in the communication overhead.