# Self-Configuring IoT Service QoS Guarantee Using QBAIoT
## 4 QBAIoT Performance Evaluation  
We describe in the following the performance evaluation details of our proposed QoS based wireless access method as well as the additional self-configuring capability enhancement. We use OMNeT++ to implement and simulate our QBAIoT access method according to several scenarios in order to evaluate the performance of our proposal. To do so, we adapt an IEEE 802.15.4 model available for OMNeT++ [32]. The adaptation consists not only in removing the CFP and inactive parts of the standard superframe but also in creating different QoS CAPs within the same superframe. We conduct various simulation scenarios grouped into different set of simulations. The simulations common parameters for all sets are specified in Table 2. \begin{table}
\begin{tabular}{c c} \hline \hline
**Parameter** & **Value** \\ \hline Simulation Time & 100 s \\ Mac Payload Size & 50 Bytes \\ Topology & Star \\ Number of coordinators per WPAN & 1 \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Common simulation parameters. Figure 13: Self-configuring process on HL-Gw. To evaluate the performance of QBAIoT according to the specified scenarios in the different sets, we take into consideration the QoS parameters included in the iSLA specified in Section 3.3. First, the average delay refers to the average time experienced by a generated packet from the IoT object to be received by the LL-Gw. It is computed by dividing the sum of received packets delays by the number of received packets. Then, the packet delivery ratio (PDR) evaluates the reliability degree achieved by the QBAIoT based sensing layer in terms of successful transmissions. It is computed by dividing the number of received packet by the number of generated packets. In the first set of simulations, we consider seven different scenarios described in Table 3 that shows the number of objects per QoS class in each scenario with the corresponding slots configuration. For all scenarios, the objects data generation interval time is fixed to 0.25 s resulting in 400 generated packets for each object during the simulation. Scenarios 1 to 4 take into consideration objects that generate the data at the same time, whereas Scenarios 5 to 7 take into consideration objects that do not generate the data at the same time. The first scenario corresponds to an IoT e-health service with three RTMC nodes resulting in allocating the 16 slots to the three nodes. The second scenario corresponds to an IoT e-health service requiring three RTMC nodes along with three RTNMC nodes. Based on the knowledge base, nine slots are allocated to RTMC nodes, and seven to RTNMC nodes. The third scenario corresponds to nine nodes (three RTMC, three RTNMC, and three streaming) resulting in 7/6/3 respectively for the slots configuration. The last scenario corresponds to the existence of 12 nodes (3 of each QoS class) resulting in a slots configuration of 6/5/3/2. Figures 14-17 show the performance evaluation comparison between our QBAIoT approach and the IEEE 802.15.4 standard according to Scenarios 1, 2, 3 and 4 correspondingly. Figure 14 presents the delay and PDR evaluation corresponding to scenario 1 with only one QoS class traffic (RTMC). We can observe that for one QoS class, QBAIoT acts like the traditional slotted CSMA/CA as one QoS class is allocated the totality of the slots. Indeed, the obtained results in terms of average delay and PDR are very close for the two approaches. In our approach, we can observe that we have a difference of 7 ms resulting from testing if the current slot is in the QoS CAP, which is not necessary in the traditional approach. The obtained results in Figure 15 show that for 2 QoS classes, QBAIoT ensures a better delay for RTMC and an identical delay for RTNMC comparing to the standard IEEE 802.15.4 access method. Allocating two more slots for RTMC compared to RTNMC results in 10 ms better average delay for this  
Figure 14: Delay and PDR evaluation for Scenario 1.