# Self-Configuring IoT Service QoS Guarantee Using QBAIoT
## 3 QoS Guarantee within Internet of Things Environment
### IoT Service Level Agreement  
The IoT-SP uses different cSLAs and nSLAs concluded with various NSPs and CSPs, in order to achieve an iSLA with the IoT-C. In the cSLAs and nSLAs, the different information and QoS guarantees regarding the IoT service on the corresponding IoT layer are agreed on. For example, in the cSLA, the number of users accessing the IoT application is indicated in order to allow the CSP to provide these users with the QoS guarantee corresponding to the cloud layer (i.e., response time, storage, etc.). Whereas, in the nSLA, the maximum bandwidth utilization is specified in order to guarantee the delay in the network layer. The different information specified in the iSLA sub agreements (i.e., cSLAs, nSLAs, gSLAs) are used to specify the service characteristics to be respected (i.e., number of users, numbers of connected objects, packets generation intervals, etc.) in order to benefit from the desired  
Figure 4: IoT Service level based global architecture for an E-health application. QoS. We specify the iSLA as a service level agreement specific to IoT environments and we use it in our proposed IoT architecture. The specified iSLA includes multiple QoS parameters corresponding to the technical part of the iSLA. The iSLA global XML schema is presented in Figure 5.  
The iSLA identifies the IoT service by a list of client IP addresses for the source side. As for the destination side, it uses an application ID, an application Interface IP along with the port number as well as the ID of the corresponding HL-Gw and LL-Gws. Furthermore, the iSLA contains an IoT service performance parameters attribute describing the IoT Sensing Characteristics as well as IoT application characteristics and IoT QoS parameters. Thus, the IoT sensing characteristics part of the iSLA includes all the characteristics of the gateways (HL-Gw, LL-Gw) and the IoT smart objects group. Then, the IoT application characteristics part of the iSLA includes parameters related to the cSLA such as the application ID, the maximum number of users, the mean number of requests per second per user, the time of support and the storage parameters. Finally, the IoT QoS parameters part of the iSLA is  
Figure 5: iSLA XML global schema. classified into two different categories; the qualitative parameters and the quantitative parameters. The qualitative characteristics define the application type by specifying the QoS class of the data generated (i.e., RTMC: real-time mission-critical, RTNMC: real-time non-mission-critical, Streaming, and NRT: non-real-time). The quantitative QoS parameters include the end-to-end delay, availability, lifetime, and data quality (standard deviation, sensing frequency, and data error ratio). Financial elements are essential in SLAs. Therefore, the iSLA contains an IoT business parameters attribute. It includes an IoT service cost part as well as IoT violations and penalties part where we specify thresholds and the monitoring interval time for each IoT QoS parameter. As a usage case, we consider an e-health service belonging to the real-time mission-critical class and we describe how to establish the corresponding iSLA within our IoT architecture in order to satisfy the requirements of such application. In this context, we present a message sequence chart that illustrates the interactions that occur between the different components of our architecture (see Figure 6). The e-health application is a real-time mission-critical application that requires a limited end-to-end delay (150 ms) with high Availability (99.999%) and a high data quality. The end-to-end delay declines into IoT application response time (cloud), the IoT sensing response time (objects) and the network delay. As for the IoT service availability, QBAIoT does not take into consideration radio noise issues. Thus, QBAIoT could provide high availability only if no noise issues exist in the sensing environment.