# Self-Configuring IoT Service QoS Guarantee Using QBAIoT
## 4 QBAIoT Performance Evaluation
\begin{table}
\begin{tabular}{c c c c c c} \hline
**Scenario** & **RTMC Objects** & **RTNMC Objects** & **Streaming Objects** & **NRT Objects** & **Slots Configuration** \\ \hline
1 & 3 & 0 & 0 & 0 & 16 \\
2 & 3 & 3 & 0 & 0 & 9/7 \\
3 & 3 & 3 & 3 & 0 & 7/6/3 \\
4 & 3 & 3 & 3 & 3 & 6/5/3/2 \\
5 & 4 & 4 & 4 & 4 & 6/5/3/2 \\
6 & 5 & 5 & 5 & 5 & 6/5/3/2 \\
7 & 6 & 6 & 6 & 6 & 6/5/3/2 \\ \hline \end{tabular}
\end{table} 
Table 3: Number of objects per QoS class in each scenario of the first set. QoS class. For the PDR evaluation, QBAIoT ensures better values for RTMC (99%) and RTNMC (98%) than the standard approach (56% and 55%, respectively). Our approach enables these performance results in terms of PDR, as only objects of the corresponding QoS class can compete to access the channel during the slots of a QoS CAP. Thus, our class-based access will avoid collisions between different traffics generated by objects belonging to different QoS Classes. Figure 16 shows the evaluation performance corresponding to Scenario 3. The obtained results shows a better delay, while using QBAIoT, for RTMC and RTNMC traffic compared to the standard. With our QoS based access method, seven slots are allocated to the RTMC traffic and six for RTNMC traffic, resulting in better delays: 33 ms less than the standard for RTMC and 16 ms less as for RTNMC. Similarly, we obtain with our approach a better PDR for this scenario, as the number of collisions is lower. Indeed, the PDR for the RTMC traffic with QBAIoT is equal to 98.5% whereas it is equal to 26% with the IEEE 802.15.4. The obtained performance results in terms of PDR and delay corresponding to Scenario 4, where the LL-Gw configures four QoS classes, are illustrated in Figure 17. In this scenario, we observe that QBAIoT enables better delays for RTMC (90 ms) and RTNMC (106 ms) traffics compared to the IEEE 802.15.4 standard access method (115 ms for RTMC and 123 ms for RTNMC). Moreover, we observe better PDR for all QoS classes (>96% for three classes) using our approach compared to the standard (<20% for all classes). Indeed, for the IEEE traditional approach, all QoS classes will be served similarly and in the same time, resulting in more collisions and approximatively four slots for each QoS class; whereas our QBAIoT access method enables different QoS CAPs to minimize collisions and configures RTMC with six slots and RTNMC with five slots in this scenario. Finally, we observe an important delay for non-real-time traffic due to the configuration of only two slots for this class, which is not sensitive to the QoS delay parameter. In the other hand, we obtain for NRT traffic a better PDR (26%) than the traditional approach (16%). Figure 16: Delay and PDR evaluation for Scenario 3. Figure 15: Delay and PDR evaluation for Scenario 2. Figure 18 shows the average delay of RTMC and RTNMC packets for Scenarios 5 to 7. In these scenarios, we increment the number of objects per QoS CAP (i.e., per QoS class) while not sending data at the same time by the objects of the same class. This difference allows minimizing the number of possible collisions in each QoS CAP and therefore serving the packets faster. We can note that with four and five objects per QoS CAP (see Figure 18), QBAIoT, using a single coordinator, is capable of delivering RTMC and RTNMC packets while respecting the real-time traffic requirements. In Scenario 7, where six objects per QoS CAP exist, QBAIoT with a single coordinator is not sufficient to respect the requirements of real-time traffics. In fact, with six objects or more per QoS CAP in the context of these simulations, the number of objects competing during each QoS CAPs induces an additional delay before serving the data packets. Thanks to our proposed IoT architecture, we are capable of coping with this problem by implementing a new QBAIoT LL-Gw (i.e., coordinator) in order to extend the capacity of the IoT environment and respect the requirements of an increasing number of QoS classes corresponding to the subscribed iSLAs.