## 8 Result Analysis
### Authentication Latency  
Authentication latency means the delay was caused by the mutual authentication, which contains the computation time both on device and edge gateway and the message propagation time. From the device's perspective, as the number of cross-domain authentications \(m\) increases, the local computation delay can be expressed as \(3T_{c}+5T_{h}+m(3T_{h}+2T_{c})\), where \(3T_{c}+5T_{h}\) represents the computation time required during the initialization phase and \(3T_{h}+2T_{c}\) denotes the computation delay incurred during mutual authentication with edge gateways in different domains. In contrast, the local computation delays of the device for the scheme [4; 10; 17; 44; 45] are \(2T_{mul}+4T_{h}+m(2T_{mul}+4T_{h})\) \begin{table}
\begin{tabular}{c c c c} \hline \hline \multirow{2}{*}{**Method**} & \multirow{2}{*}{**Device Side (bits)**} & \multirow{2}{*}{
\begin{tabular}{c} **Edge Gateway** \\ **Side (bits)** \\ \end{tabular} } & \multicolumn{2}{c}{**Overall**} \\  & & & **Communication** \\  & & & **Cost (bits)** \\ \hline [PERSON], [PERSON] et al. [4] & 672 & 800 & 1472 \\ [PERSON] et al. [10] & 613 & 613 & 1226 \\ [PERSON], [PERSON] et al. [14] & 584 & 584 & 1168 \\ [PERSON], [PERSON] et al. [16] & 240 & 236 & 476 \\ [PERSON], [PERSON] et al. [30] & 1376 & \(-\) & 1376 \\ [PERSON] et al. [33] & 536 & 536 & 1072 \\ [PERSON] et al. [45] & 800 & 800 & 1600 \\ [PERSON] et al. [44] & 832 & - & 832 \\ Our Method & 660 & 410 & 1070 \\ \hline \hline \end{tabular}
\end{table} 
Table 4: Comparison of communication cost with related work. \(2T_{mul}+2T_{h}+m(3T_{mul}+3T_{h})\), \(3T_{mul}+2T_{h}+m(9T_{mul}+5T_{h}+4T_{add})\), \(6T_{h}+m6T_{h}\), and \(6T_{p}+(4m-1)T_{mul}+(m+6)T_{h}\), respectively. As illustrated in Figure 7a, the scheme [45] exhibits the lowest computation delay, as it relies solely on hash operations for device-to-gateway authentication. Our scheme achieves the second-lowest computation overhead by replacing computationally intensive elliptic curve scalar multiplication and addition with Chebyshev chaotic map operations. From the perspective of the edge gateway, as the number of cross-domain authentications \(m\) increases, the local computation delay can be expressed as \(3T_{c}+6T_{h}+m(4T_{h}+2T_{c})\), where \(3T_{c}+6T_{h}\) represents the computation time required during the initialization phase and \(4T_{h}+2T_{c}\) denotes the computation delay incurred during mutual authentication with devices from other domains. In comparison, the local computation delays of the edge gateway for the scheme [4; 10; 17; 44; 45] are \(2T_{mul}+5T_{h}+m(2T_{mul}+5T_{c})\), \(3T_{mul}+3T_{h}+m(4T_{h}+5T_{mul}+3T_{add})\), \(2T_{mul}+2T_{h}+m(7T_{mul}+5T_{h}+3T_{add})\), \(12T_{h}+m(4T_{mul}+12T_{h}+T_{add})\), and \((3m+1)T_{p}+(m+2)T_{mul}+(m+3)T_{h}\), respectively. As illustrated in Figure 7b, our proposed scheme achieves the lowest computation delay on the edge gateway side, outperforming scheme [45]. This is because scheme [45] offloads the computationally intensive elliptic curve operations required for device authentication onto the more powerful edge gateway, whereas our scheme avoids such operations entirely by adopting lightweight Chebyshev chaotic map-based computations. Above all, the overall authentication latency can be approximated as \(m(3T_{h}+2T_{c})+m(4T_{h}+2T_{c})+m(T_{DE}+T_{BQ})\), where \(T_{DE}\) denotes the message transmission delay from the device to the edge gateway and \(T_{BQ}\) represents the latency associated with querying the blockchain. According to [44], \(T_{DE}\) is approximately 100 ms, and based on our experimental results, \(T_{BQ}\) is around 15 ms.