# Self-Configuring IoT Service QoS Guarantee Using QBAIoT
## 4 QBAIoT Performance Evaluation
The second set of simulations allows evaluating the self-configuring capability of our QoS based access method. Indeed, we evaluate the impact of providing different superframe slots configurations according to the characteristics of the IoT environment. Furthermore, self-configuring QBAIoT enables different beacon configurations for the same number of QoS classes according to the number of RTC classes. For the second set of simulations, we use an IoT environment including three different QoS classes for the first two scenarios. Every QoS class includes three nodes with a data generation interval of 0.25 s per node. Different configurations are available in Table 1 depending on the number of RTC among the three QoS classes of the considered simulation environment. Consequently, two scenarios are presented. Scenario 1 corresponds to the existence of two RTC and one NRTC traffics, whereas Scenario 2 corresponds to the existence of one RTC and two NRTC traffics. In Figure 19, we compare the average delay of each traffic corresponding to these two scenarios while using QBAIoT and the  
Figure 17: Delay and PDR evaluation for Scenario 4. Figure 18: QBAIoT average delay for RTMC and RTNMC traffics. IEEE 802.15.4 slotted CSMA/CA. The obtained results show that QBAIoT offers better delays for QoS CAP1 and QoS CAP2 traffics, whereas, QoS CAP3 traffic (delay tolerant traffic: streaming or NRT traffic) experiences a more important delay. Indeed, in Scenario 1, 2 RTC traffics are available within the IoT environment. Therefore, the two traffics should observe a minimal delay while prioritizing QoS CAP1 traffic. The corresponding slots configuration offers an additional slot to QoS CAP1 and allows respecting the interactive characteristic of the two RTC real-time traffics (a delay of 69 ms for QoS CAP1 traffic and a delay of 70 ms delay for QoS CAP2). Scenario 2 includes a single RTC traffic. Consequently, the delay QoS parameter is not critical for QoS CAP2 and QoS CAP3. In this context, we provide QoS CAP1 with eight slots enabling to further minimize the corresponding delay. As a result, we obtain a delay of 58 ms for QoS CAP1 comparing to the 69 ms delay in Scenario 1. The obtained results show that QBAIoT performs better than the IEEE 802.15.4 standard thanks to specific configurations enabling achieving the requirements of different traffic types in various scenarios depending on the environment characteristics. We consider a third scenario in the second set of simulations. In this context, the IoT environment contains four QoS classes initially. After a period of time, the IoT-SP deletes gSLAs from the HL-Gw due to the cancellation of two iSLAs and therefore, only two RTC traffics remain in the LL-Gw environment. Initially, every QoS class includes three nodes. After 15 s of the simulation beginning, the gSLA concerning the Streaming and NRT traffics are removed and their corresponding traffics are stopped. We compare in Figure 20 the average delay while using or not QBAIoT self-configuring capability for the highly critical data (RTMC and RTNMC). In this scenario, without QBAIoT self-configuring capability, the HL-Gw is not able to change the initial configurations without human intervention. Consequently, the slots allocated to streaming and NRT traffics remain not used during every superframe after deleting the corresponding gSLAs. Thus, for each superframe, five slots are lost resulting in a usage of 68% (11/16 slots) of the superframe slots. The obtained results illustrated in Figure 20 show that, with a self-configuring QBAIoT enabling the usage of these lost slots due to environment changes, the delay of RTMC and RTNMC traffics are improved in a way to respond better to real-time traffic requirements. Furthermore, the QBAIoT self-configuring capability enhancement enables better superframe slots usage. Figure 21 shows the obtained results concerning the PDR performance parameter for RTMC and RTNMC traffics while using QBAIoT with and without self-configuring capability according to the same Scenario 3.