of adapting themselves in real-time to meet the needs of different user flows. The QoS requirements for different layers of the architecture must then be translated such that they are comprehensible to the other layers. This translation allows different IoT layers to communicate with each other in order to meet QoS requirements. Consequently, guaranteeing end-to-end QoS in the IoT first requires breaking down QoS needs according to the different layers of the IoT architecture and then finding mechanisms to apply in a complementary manner between these layers.
1.5.2.4.2. Research projects
Various projects and research studies have been carried out with the aim of studying the guarantee of QoS in the IoT environment based on a transversal approach involving the different layers of the IoT architecture. We present below a non-exhaustive list of proposals produced by these studies.
SymbIoTe, a European project funded by H2020 (January 2016–January 2019) (Zarko et al. 2015), aims to offer a system providing IoT services if the availability and QoS potentially associated with this can be guaranteed by the underlying infrastructure. The IoT system must prioritize privileged users over basic users if there are simultaneous attempts to access certain IoT services. This priority must be ensured across all IoT layers in order to guarantee end-to-end QoS. In addition, the system must allow access control to IoT services in accordance with local and global legislation (security of access to critical data is a necessary requirement requested by several governments and international organizations), the current overload, security issues, etc. This access control must be provided across all IoT layers (Zarko et al. 2015).
In addition, several research projects have studied the transversal approach to guaranteeing QoS in the IoT environment. The research work presented in Duan et al. (2011), for example, is based on the principle that two adjacent layers in the IoT architecture communicate with each other to provide QoS. The upper layers send a QoS query to the layer that is directly beneath, which translates the request into a number of QoS parameters. This interlayer communication is carried out using dedicated interfaces with clearly specified parameters. The QoS for the support and application layer in the IoT architecture is directly perceived by the clients and is based on parameters such as time of service, precision, load and priority. The network layer QoS depends on the network type and is based on parameters like bandwidth, delay, jitter, and packet loss ratio, etc. Finally, QoS for the device layer is based on parameters of sampling, coverage, synchronization and mobility. It is useful to differentiate services in order to identify different service levels and attribute these to clearly defined IoT applications. In addition, each level corresponds to a number of specific QoS requirements. The research work conducted in Duan et al. (2011) organized applications into four classes depending on the type of task to be performed. The four categories of applications specified are as follows: Guaranteed Service, Guaranteed Service/Differentiated Service, Differentiated Service, and Best Effort. Therefore, IoT control applications require Guaranteed Service, IoT queries require Guaranteed and Differentiated services, IoT real-time surveillance applications require Differentiated Services, while non-realtime surveillance applications require Best Effort services.
1.6. QBAIoT: QoS-based access method for IoT environments
In order to guarantee a service level within the IoT, in Khalil et al. (2017) we propose a framework based on an architecture that enables QoS guarantee through the establishment of different types of SLA.
1.6.1. Service level guarantee in the IoT
1.6.1.1. QoS-based architecture for the IoT
We propose the architecture illustrated in Figure 1.3 in order to allow an IoT service provider (IoT-SP) to provide a service to a client (IoT-C) in accordance with a service level agreement (iSLA:IoT-SLA).
Figure 1.3. Architecture of the Internet of Things (Khalil et al. 2018)
The proposed architecture is based on three layers (sensing, network and Cloud) and different entities, each playing a specific role. IoT-C requests a service from the IoT-SP. The requested service uses an infrastructure of objects owned by the customer or the IoT-SP. In addition, the IoT-SP may have its own Cloud infrastructure or it subscribes to specific SLAs with different Cloud Service Providers (CSP). On the other hand, IoT-SP also subscribes to SLAs with different network service providers (NSP) to interconnect object infrastructures to Cloud resources. The IoT service requires an application part and an object infrastructure part.
The object infrastructure retrieves information or executes orders. It is managed by a High-Level Gateway (HL-Gw) that aggregates the data before they are sent to the Cloud in order to guarantee minimum bandwidth consumption. In addition, this HL-Gw offers local data processing capabilities (fog computing). Low-Level Gateway (LL-Gw) on the other hand classifies the data for differentiation and ensures the application of QoS at the lowest layer of the proposed IoT architecture (sensing layer or device layer, according to ITU-T). The application part of the IoT service enables the monitoring of objects during the execution of orders or during data processing. It is generally hosted in the Cloud infrastructure and can be provided in different forms depending on the service that has been subscribed with the CSP (IaaS, SaaS and PaaS) (Khalil et al. 2017).
An SLA between the provider and the customer allows the expected characteristics of the IoT service to be defined. In the context of our IoT architecture, the SLA must include customer expectations and provider guarantees with respect to the three layers (sensing, network and Cloud). Thus, our global IoT-SLA (iSLA), established between the IoT-SP and the IoT-C, is based on different sub-SLAs established between the IoT-SP and CSP (called cSLA: cloud SLA), and the NSP (called nSLA: network SLA). In addition, an internal SLA is established between the IoT-SP and the HL-Gw (called gSLA: gateway SLA). The cSLA includes performance and QoS parameters depending on the type of subscribed Cloud service. The performance parameters of an IaaS service differ from those of the PaaS and SaaS services. Thus, a SaaS service response time may be sufficient for measuring performance, while for an IaaS service, the cSLA client is offered an infrastructure and, consequently, performance must be measured through other parameters, such as computing capacity and storage capacity. The nSLA is based on conventional network QoS parameters such as bandwidth, latency, jitter, packet loss ratio and availability. The gSLA describes the processing and storage capacities used by the IoT service at the HL-Gw. It also includes the characteristics of LL-Gw and those of the object infrastructure used for offering the IoT service (Khalil et al. 2017).
1.6.1.2. Service level agreement in the IoT
The IoT-SP establishes a service level contract called iSLA with the IoT-C using a set of subcontracts such as cSLA and nSLA, implemented with various NSPs and CSPs. The global iSLA type agreement makes it possible to identify the IoT service using the “Service Identification” attribute. At the client’s end, this attribute is based on a list of IP addresses used by the IoT-C. At the supplier’s end, an application identifier, the IP address of the application interface, the port number as well as the identifiers of the HL-Gw and LL-Gw are used. In addition, the iSLA-type agreement includes an attribute for “IoT Service Performance Parameters” that describes the characteristics of the IoT service using three subattributes: “IoT Sensing Characteristics”, “IoT Application Characteristics” and “IoT QoS Parameters”. Thus, the “IoT Sensing Characteristics” section includes the characteristics of the gateways (HL-Gw and LL-Gw) and of the group of IoT objects (i.e. inter- and intragateway communication technology, number of objects connected by LL-Gw, number of LL-Gws per HL-Gw, etc.). The “IoT Application Characteristics” section includes parameters related to cSLA such as the application identifier, the maximum number of users, the
