# Device Centric Throughput and QoS Optimization for IoTsin a Smart Building Using CRN-Techniques
## 5 Performance Evaluation
### Comparison Based on Blocking Probability  
In this section, we compare the proposed scheme based on the combined blocking probability (i.e., 1-normalizedvalue of \(\mathcal{F}\)) by varying the number of channels, SoC and traffic load. For these results, we consider the low traffic scenario and plot the blocking probability of SUs. Since there are 20 channel requests from SUs, at least 20 channels are required to provide wireless connectivity (there may be higher collisions if only 20 channels are available). However, the greater the availability of vacant channels, the lesser the blocking probability (collisions with the PU are reduced). Figure 10 shows the blocking probability for different numbers of available channels and indicates that the blocking probability decreases with the increase of available channels. The proposed scheme shows significantly lower blocking rates as compared to the other schemes. For example, consider a case when \(N=60\) channels are available; the proposed scheme shows 40% less collision probabilities as compared to GCS, and it offers a three-times lesser blocking rate as compared to the RCS and max-min fair (MMF) schemes. The MMF scheme provides the same data rate to all SUs, regardless of their QoS requirements. With the availability of \(N=100\) channels, the proposed scheme shows a blocking probability of 0.01, whereas the blocking probabilities for GCS, MMF and RCS are 0.05, 0.25 and 0.265, respectively, which are significantly higher as compared to the proposed scheme. This comparison shows that if a large number of channels is available, then the proposed scheme accommodates almost all of the requests from mobile users, IoT and NM. Figure 11 compares the proposed scheme with the existing schemes based on the SoC. With SoC \(\theta_{k}<0.3\), (i.e., the minimal SoC requirement of web traffic), not a single web-class SU gets the channel because the SoC cannot meet the minimum QoS requirement. However, when the SoC of available channels is greater than 0.3, the blocking probability decreases because the QoS demand of web users is satisfied, and they get the channel for different web services. Similarly, when the SoC becomes greater than 0.5 (i.e., \(\theta_{k}>0.5\)), the SUs that belong to video class get the chance for transmission, and the overall blocking probability reduces quickly. There is a sharp decline in the blocking probability of the network with the availability of channels with \(\theta_{k}>0.7\). This is due to the fact that other classes receive service due to the availability of stable channels. Consider a case for \(\theta_{k}=0.7\); the proposed scheme shows [17.7% 55% 71%] low blocking probability as compared to the GCS, MMF and RCS, respectively. Hence, the proposed scheme offers the better quality channels to SUs. Figure 9: Cumulative distribution function of SoC. Figure 12 compares the proposed scheme with the existing scheme in terms of IoT density. We vary the number of IoT devices belonging to different classes who are demanding channels for data transmission and plot the average blocking probabilities for different schemes. It is clear from the line chart of Figure 12 that the proposed scheme shows significantly lower blocking probability as compared to other schemes. For example, with 100 IoT devices that are requesting channels for data delivery, the proposed scheme shows 12.33% lower blocking probability compared to the GCS scheme and shows 31.66% less blocking probabilities in comparison with MMF and RCS, respectively. Hence, our scheme is well suited for the smart-building environment in order to cater to a large density of IoT devices. The blocking probabilities of individual classes are presented in Table 5 for low and high traffic modes. The comparison is shown for four different classes, such as voice, web, _lvid_ (i.e., \(I\) indicates that it is a video IoT device) and NM. The web traffic of SU and the video traffic of IoT show higher blocking probabilities due to their stringent QoS requirements, as compared to the voice and NM traffic.