Service Level Management in Emerging Environments. Nader Mbarek

Чтение книги онлайн.

Читать онлайн книгу Service Level Management in Emerging Environments - Nader Mbarek страница 15

Service Level Management in Emerging Environments - Nader Mbarek

Скачать книгу

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.

      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.

      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).

      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

Скачать книгу