# Self-Configuring IoT Service QoS Guarantee Using QBAIoT
## 3 QoS Guarantee within Internet of Things Environment
### IoT Service Level Based Architecture  
We propose a service level-based architecture (see Figure 4) while considering an e-health service scenario enabling an IoT-SP to deliver to an IoT-C an IoT service in conformance with a global iSLA. The proposed architecture, compliant with the ITU-T reference model, is based on four layers (sensing, gateway, network, and cloud) as well as different entities that each have a specific role:  
* The IoT-C requests a service from the IoT Service Provider and can use an IoT objects infrastructure provided by the IoT-SP or its own infrastructure. The IoT-C is not necessarily the end user of the IoT service. Indeed, it can be the organism in charge of the end users.
* The IoT-SP offers IoT services for different IoT-Cs. It has its own cloud infrastructure or subscribes specific SLAs with different cloud service providers (CSPs). The cloud infrastructure stores the huge amount of data created, provides computation capabilities and hosts different IoT applications. In addition, the IoT-SP subscribes SLAs with different network service providers (NSPs) to interconnect the IoT objects infrastructure with the corresponding cloud infrastructure.  
The IoT service is divided into two parts: an application part and an objects infrastructure part. The objects infrastructure is managed by two categories of gateways in order to retrieve information or execute orders. The first category of gateways is called high level gateways (HL-Gws). They ensure minimal bandwidth consumption while transmitting data to the cloud using the data aggregation techniques and offer fog computing capacities for non-delay tolerant data processing in order to minimize the corresponding end-to-end delay. The second category consists in low level gateways (LL-Gws) that are used to ensure not only data classification for processing differentiation but also management of objects' clusters. On the other hand, the application part of the IoT service is usually hosted on the cloud infrastructure and can be provided as a software as a service (SaaS) by the CSP or developed by the IoT-SP while using a platform as a service (PaaS) or an infrastructure as a service (IaaS).  
A SLA concluded between the IoT-SP and the IoT-C allows defining the expected service characteristics. In the context of our IoT architecture, the SLA should include clients' expectations relative to all specified layers and components: devices, network, data and cloud. Thus, our proposed global IoT-SLA (iSLA) specified between the IoT-SP and the IoT-C is based on different sub-SLAs concluded with the CSP (cSLA: cloud SLA) as well as the NSP (nSLA: network SLA). The _cSLA_ includes performance parameters according to different types of available cloud services (IaaS, PaaS, SaaS). As for the nSLA, it is based on traditional QoS network parameters such as bandwidth, latency, jitter, packet loss ratio, and availability. In addition, an internal SLA, called gSLA (gSLA: gateway SLA), is specified on the HL-Gw and includes the different characteristics of the IoT service processing within the gateways. We presented in our previous work [31] a detailed description of these service level agreements.