# Self-Configuring IoT Service QoS Guarantee Using QBAIoT
## 3 QoS Guarantee within Internet of Things Environment
### QBAIoT: QoS Based Access for IoT  
In order to guarantee the negotiated values of the QoS parameters specified in the iSLA of our e-health usage case and illustrated by the MSC of Figure 6, we propose in this research work a novel QoS mechanism concerning the sensing layer of our IoT architecture. Indeed, we specify a QoS based wireless access method called QBAIoT enabling a QoS based communication between the IoT objects and the low-level gateway of our IoT architecture. The proposed QoS mechanism is an enhancement of the IEEE 802.15.4 slotted CSMA/CA process in order to allow a traffic differentiation while satisfying the QoS requirements of each traffic type (for example: minimal delay for delay sensitive applications, etc.).  
Our QBAIoT method is based on the IEEE 802.15.4 standard while adapting its superframe structure to satisfy the requirements of different traffic types available within the IoT environment. Indeed, we can take into consideration up to four QoS classes that we define in our iSLA qualitative characteristics (RTMC, RTNMC, Streaming, and NRT). Real-time traffics (RTMC and RTNMC) are highly sensitive to delay, whereas streaming traffic is highly sensitive to jitter variation and the NRT traffic is a best-effort QoS class. To adapt the structure of the superframe to these QoS classes, we specify different CAPs within the standard IEEE 802.15.4 superframe. Each CAP is specific for one QoS class and it is called a QoS CAP. Our adapted superframe structure contains up to four QoS CAPs (see Figure 7). The number of QoS CAPs configured in the adapted superframe within our low-level gateway (LL-Gw) depends on the number of QoS classes specified in the iSLAs that concern these LL-Gws. Furthermore, we do not use neither a CFP period nor an inactive part in our adapted superframe. The removal of the inactive part results in minimizing the delay for real-time buffered data.  
During each QoS CAP, only objects belonging to the corresponding QoS class can compete to gain access to the shared medium. Each QoS CAP is allocated a number of slots. The slots configuration and the fixed values of BO and SO depends on the number of available QoS classes and the number of real-time QoS classes. If only one QoS class exists, the standard IEEE 802.15.4 superframe structure will be used in our architecture but without CFP and inactive periods, as a single QoS CAP exists.  
Figure 7: IEEE 802.15.4 and QBAIoT superframe structure.  
In the case of multiple QoS classes, BO and SO will be initialized to a value equal to 2 if there is at least one real-time QoS class and to a value equal to 3 if there is no real-time QoS classes. The value of BO and SO allows computing the superframe duration, consequently, the slot duration and the delay that the objects have to wait to be in their corresponding QoS CAP. Our QBAIoT access method is implemented on the LL-Gw (acting as a coordinator) as well as the IoT objects. Therefore, we describe in the following the design details of the proposed wireless access method not only for the IoT gateway but also for the IoT objects.