Читать книгу Service Level Management in Emerging Environments - Nader Mbarek - Страница 49

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