## 5 Results and Performance Analysis  
In this section, we provide the findings and a performance analysis to evaluate the performance of our proposed framework. We evaluate performance metrics such as response time, routing overhead, throughput, transaction delay, authentication, encryption, and decryption. Compared to the existing one, our proposed framework gave a better response time and less delay. Our framework provided the best throughput compared with existing models. Our permissioned blockchain uses a consensus method optimized for low resources, resulting in a substantially lower computational cost than classic proof-of-work systems. Our method reduces this effect by shifting blockchain-related calculations to edge devices (coordinators), which eases the burden on individual nodes. Edge-Based Processing: Blockchain processes like validation and block building are offloaded to competent edge devices or coordinators, reducing processing strain on individual Zigbee nodes. The blockchain logs only crucial security-related transactions, such as attack notifications and key upgrades. Routine data and logs that are not time sensitive are kept off-chain to reduce transaction traffic and delay. Optimization Techniques: Batch processing, asynchronous updates, and selectively reporting important security events on-chain minimize disturbance by batching transactions and allowing for background changes.These methods work together to keep Zigbee networks running smoothly and efficiently while maintaining low latency. Our frameworks offers asynchronous consensus updates, enabling regular network activities to continue uninterrupted while the blockchain is synchronized. This architecture strikes a compromise between security assurance and the real-time operating requirements of Zigbee networks. RBF is suitable for nonlinear data. Zigbee-enabled IoT network device and traffic are diverse and dynamic, and data often show nonlinear patterns. It accurately simulates nonlinear decision boundaries. RBF networks are often less computationally demanding and need less training time, which makes them suitable for real-time or resource-constrained IoT applications. RBF effectively and efficiently understands and comprehends selected models because it strikes more of a balance between speed, performance, and interpretability than other ML models. SVMs become computationally costly when dealing with huge datasets, particularly when they include a lot of features and adjusting the kernel settings might be delicate and complicated. The Random Forest model performs well on structured data, but in our scenario, it was less able to generalize to unknown anomaly detection. CNNs are not the greatest match for tabular or temporal data, which is often seen in IoT traffic logs, even though they work well for image-based or geographical data. They need large, labeled datasets and significantly more computing resources. It does not fit for Zigbee devices which are low-power devices. The request and response time between the Zigbee creation and adding the block to pBCT network takes 57.44 ms. The key generation from the pBCT network takes the average response time as depicted in Figure 17. The request and response time for adding a block to the PBFT network from Zigbee creation is measured at 57.44 ms. Key generation from the PBFT network exhibits an average response time, with a maximum of 12.46 ms for key pair generation. Additionally, signature creation and verification times for Zigbee coordinators are 32.45 ms and 30.3 ms, respectively, indicating the computational efficiency of the proposed system, see Figure 18. For generating the key pair, the maximum response time is 12.46 ms. The creation of the signature takes 28.18 ms and the verification of the signature takes 26.9 ms by the Zigbee coordinators. For the Zigbee coordinators, the creation of the signature takes 32.45 ms and the verification of the signature takes 30.3 ms. The edge device needs to be validated properly by the Zigbee coordinators.