Internet of Things (IoT) is nowadays evident in our everyday life. We estimate the economic impact of the IoT to be between $
3.9 and $
11 trillion dollars by 2025 [1
]. Indeed, billions of connected objects exist with an average of two devices per human on earth resulting in creating the IoT environment [2
]. The future growth of IoT will lead to an important usage of technology in our daily life. Thus, this usage of technology aims to improve the human’s quality of life by facilitating everyday tasks. To ensure better user experience and improve the usage of IoT applications, a certain service level corresponding to specific IoT services is needed to motivate the users to use the IoT applications. The expected service level should consider not only QoS guarantee, measured through different performance parameters (i.e., delay, packet delivery ratio, etc.), but also security and users’ privacy issues within different layers of the IoT architecture [3
]. We consider in this paper the QoS part of a service level and we specify a QoS mechanism enabling the guarantee of a service level prior to the IoT service subscription. In this context, the IEEE 802.15.4 standard is used as a base for different communication technologies in the IoT environment and specifically in the e-health application domain. Thus, we specify a novel QoS based wireless access method for IoT environments called QBAIoT. Our method is an enhancement of the slotted Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) technique, used by the beacon-enabled mode of the IEEE 802.15.4 standard. In this paper, we extend our previous work [5
]. The objective of the proposed method is to guarantee QoS parameters corresponding to the requirements of a specific IoT service such as e-health. These requirements are specified into a contract called IoT SLA (iSLA) negotiated between the IoT Service Provider (IoT-SP) and the IoT Client (IoT-C). In this research work, we aim to present the design details and performance evaluation of our proposed QBAIoT access method and its usage in an IoT architecture in order to satisfy the requirements of an e-health service according to a proposed iSLA. In addition, we present an enhancement of QBAIoT considering a self-configuring capability for minimizing human intervention and responding to the IoT environment changes. The reminder of the paper is organized as follows. We present in Section 2
the state of the art concerning the IoT environment, the self-management in IoT and the important characteristics of the IEEE 802.15.4 technology. Section 3
describes the QoS motivations in the IoT as well as our service level based IoT architecture along with the proposed iSLA and its establishment. Then, we specify in the same section our proposed method enabling QoS based access for IoT environments and the corresponding self-configuring capability. Section 4
presents a detailed performance evaluation of our novel self-configuring access method while we compare it to the standard IEEE 802.15.4 access method as well as another QoS based access method called SDA (Service Differentiated and Adaptive) CSMA/CA. Finally, we conclude the paper in Section 5
and present future works.
3. QoS Guarantee within Internet of Things Environment
In order to provide IoT objects with QoS guarantee according to a negotiated service level between the IoT-SP and the IoT-C, we have to deploy various QoS mechanisms at different layers of the IoT architecture. We describe in the following the QoS challenges and motivations in the IoT environment. Then, we present our service level based IoT architecture as well as our QoS adaptation of the slotted CSMA/CA access method used in IEEE 802.15.4.
3.1. QoS Motivation and Challenges in IoT
The exponential increasing number of IoT connected objects leads to a greater amount of data created in the IoT environment. In addition, the generated data has different and even contradictory characteristics that we have to cope with by providing QoS guarantee within the IoT environment, which is a challenging task. QoS models such as IntServ and DiffServ are difficult to be used within the IoT environement due to the constraints in terms of memory and computing capacity of IoT objects but also due to the large scale of the IoT and the random deployment of objects. Therefore, new and well-adapted QoS models must be proposed to provide IoT services performance guarantees [24
]. Various international organizations consider that QoS integration in IoT environments is very important and necessary. The ITU-T describes the importance of integrating QoS into the IoT environment through their Y.2066 document [21
]. They focus on the importance of service priority in order to satisfy specific requirements of different IoT services during congestion periods that are frequent due to the huge amount of generated data in the IoT. Indeed, during congestion periods, IoT traffic performance will be affected and especially the performance of QoS constrained data streams. In order to avoid performance degradation when delivering critical data, an effective and optimized management of the available resources is necessary to guarantee a certain service level in the IoT environment. This service level guarantee is possible thanks to the specification of QoS mechanisms in different layers of the IoT architecture in order to satisfy different QoS requirements and parameters such as delay, jitter, bandwidth, and packet loss ratio for various traffic types [25
]. Furthermore, these QoS mechanisms must take into consideration different components of the IoT environment (sensing, gateway, network, and cloud) in order to achieve an end-to-end service level guarantee for IoT services.
Different research works developed approaches to integrate the QoS in different layers of the IoT architecture. OpenIoT [22
], a FP7 funded European project, had presented different QoS parameters for the IoT environment. Each parameter has its own set of metrics: energy consumption associated to the lifetime of the sensor layer, data volume produced by the sensors, trustworthiness correlated to the quality of sensor, etc. Traditional metrics had been also used by OpenIoT such as the jitter, the delay, etc. All these metrics are used to define the service level expected by the client and to specify the requirements of each IoT service. In addition, this European research project proposed a QoS manager that keeps tracking of the defined metrics for guaranteeing the service level. Furthermore, different research works proposed the integration of QoS mechanisms within the lower layer of the IoT architecture. F-Interop Platform [26
] is a H2020 European funded research project that focuses on developing online interoperability and performance test tools for the IoT environment. Remote online testing software was proposed to measure the QoS, the scalability and the energy in such environment. The collection of statistics in F-Interop testing tools can be ensured by using a passive or an active method thanks to software defined networking (SDN) and network functions virtualization (NFV) techniques. QUASIMODO [27
], a French national research project, proposed different methods and algorithms for providing an end-to-end self-adaptive QoS support for real-time applications and energy efficiency in wireless sensor networks (WSN) and IoT systems. Different issues are studied for guaranteeing the QoS. Thus, QUASIMODO presented a routing protocol for multi-hop routing under multi-constraints (energy, link reliability, delay). It is based on the operator calculus algebra and it was successfully implemented on Contiki/TelosB platform. Furthermore, several academic research projects focused on the guarantee of service level in the IoT environment. In [28
], the authors presented a three-layer architecture for the IoT environment (perception layer, network layer, and application and service layer). The architecture includes also a cross-layer QoS management facility as well as QoS brokers for supporting end-to-end QoS operations. In fact, the broker is responsible for resolving QoS requirements received from the upper layer and translating them to QoS requests on the local layer. The QoS requirements are a set of performance parameters to be respected. In this work, the authors had grouped the IoT applications into different types, and assigned a QoS level to each application type. Indeed, control applications need a guaranteed service, query applications need a guaranteed or a differentiated service, real-time monitoring applications need a differentiated service, while the non-real-time monitoring applications need best effort service. The research work conducted in [29
], specifies different queues and a scheduler within an object in order to ensure a specific priority while processing QoS constrained flows. Moreover, some research works tried to adapt the slotted CSMA/CA algorithm to ensure a QoS guarantee. The research conducted in [30
] had adapted the IEEE 802.15.4 standard and specifically the slotted CSMA/CA algorithm by integrating a QoS mechanism. This approach is called SDA-CSMA/CA and is based on the specification of different values of CSMA/CA variables (contention window, minimal and maximal BE) enabling different priorities according to traffic types. Thus, three priority levels are considered while using SDA-CSMA/CA. In this context, smaller CWs and BE intervals (minimal BE and maximal BE) are assigned to high-priority traffics. Consequently, important messages have higher chances for channel access with shorter backoff time.
3.2. 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.
3.3. 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 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 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. As shown in the MSC (see Figure 6
), the IoT-C initiates the iSLA establishment by sending a request concerning the desired IoT service with its requirements. Then, the IoT-SP will classify the requirements into three types; cloud requirements, network requirements and gateways/sensing requirements. After this classification step, the IoT-SP chooses among the best offers available from the different CSPs and NSPs in order to serve the IoT-C. The IoT-SP initiates a cSLA request to the corresponding CSP and waits for his proposal. If the proposed cSLA meets the specified requirements, a cSLA Acceptance will be sent by the IoT-SP. Similarly, an nSLA request is initiated by the IoT-SP. The corresponding NSP should send its proposal and the IoT-SP accepts it if the requirements are satisfied. Afterwards, the IoT-SP evaluates the available resources on the corresponding HL-Gw to be used by the IoT-C requested service. A report about gateway resources’ availability is collected by the IoT-SP. Based on this report, the IoT-SP concludes an internal SLA called gateway SLA (gSLA) with the existing HL-Gw or with a new implemented one. Thus, the IoT-SP has the capability to propose an iSLA to the IoT-C based on the cSLA, nSLA, and gSLA. If this offer is accepted by the IoT-C, the IoT-SP concludes the cSLA and nSLA with the CSP and NSP, configures the HL-Gw, LL-Gw, nodes and the application instance. Finally, the e-health IoT service is available for usage by the IoT-C users.
3.4. QBAIoT: QoS Based Access for IoT
In order to guarantee the negotiated values of the QoS parameters specified in the iSLA of our e-health usage case and illustrated by the MSC of Figure 6
, we propose in this research work a novel QoS mechanism concerning the sensing layer of our IoT architecture. Indeed, we specify a QoS based wireless access method called QBAIoT enabling a QoS based communication between the IoT objects and the low-level gateway of our IoT architecture. The proposed QoS mechanism is an enhancement of the IEEE 802.15.4 slotted CSMA/CA process in order to allow a traffic differentiation while satisfying the QoS requirements of each traffic type (for example: minimal delay for delay sensitive applications, etc.).
Our QBAIoT method is based on the IEEE 802.15.4 standard while adapting its superframe structure to satisfy the requirements of different traffic types available within the IoT environment. Indeed, we can take into consideration up to four QoS classes that we define in our iSLA qualitative characteristics (RTMC, RTNMC, Streaming, and NRT). Real-time traffics (RTMC and RTNMC) are highly sensitive to delay, whereas streaming traffic is highly sensitive to jitter variation and the NRT traffic is a best-effort QoS class. To adapt the structure of the superframe to these QoS classes, we specify different CAPs within the standard IEEE 802.15.4 superframe. Each CAP is specific for one QoS class and it is called a QoS CAP. Our adapted superframe structure contains up to four QoS CAPs (see Figure 7
). The number of QoS CAPs configured in the adapted superframe within our low-level gateway (LL-Gw) depends on the number of QoS classes specified in the iSLAs that concern these LL-Gws. Furthermore, we do not use neither a CFP period nor an inactive part in our adapted superframe. The removal of the inactive part results in minimizing the delay for real-time buffered data.
During each QoS CAP, only objects belonging to the corresponding QoS class can compete to gain access to the shared medium. Each QoS CAP is allocated a number of slots. The slots configuration and the fixed values of BO and SO depends on the number of available QoS classes and the number of real-time QoS classes. If only one QoS class exists, the standard IEEE 802.15.4 superframe structure will be used in our architecture but without CFP and inactive periods, as a single QoS CAP exists. In the case of multiple QoS classes, BO and SO will be initialized to a value equal to 2 if there is at least one real-time QoS class and to a value equal to 3 if there is no real-time QoS classes. The value of BO and SO allows computing the superframe duration, consequently, the slot duration and the delay that the objects have to wait to be in their corresponding QoS CAP. Our QBAIoT access method is implemented on the LL-Gw (acting as a coordinator) as well as the IoT objects. Therefore, we describe in the following the design details of the proposed wireless access method not only for the IoT gateway but also for the IoT objects.
3.4.1. IoT Gateway QoS Based Access Method
The IoT LL-Gw of our architecture adopts the proposed QBAIoT mechanism as a QoS based access method enabling QoS guarantee for IoT objects according to an achieved iSLA. We specify in Figure 8
the finite state machine that illustrates the QBAIoT process within the LL-Gw.
In state S0, the LL-Gw tests if there is a new configuration to be sent to the objects of its cluster. This new configuration is specified by the HL-Gw thanks to a QBAIoT self-configuring capability (cf. Section 3.5
). Thus, if a new configuration exists, the LL-Gw updates the former beacon and sends it to the IoT nodes while reaching State S1. If there is no new configuration the beacon is sent directly to the IoT nodes at the beacon interval time and the LL-Gw switches to state S1. In State S1, the LL-Gw receives data from the different nodes according to their QoS CAPs. The LL-Gw counts the number of received packets during each QoS CAP enabling a self-optimizing capability that is out of the scope of this paper. At the end of each superframe, the number of received packet during the different QoS CAPs is communicated to the HL-Gw and the LL-Gw switches to state S0.
The QBAIoT process within the LL-Gw is illustrated in Figure 9
. In this context, the LL-Gw specifies the beacon configuration according to the received values. Then, the beacon is sent to the IoT nodes if there is at least one existing traffic in the IoT environment. The existence of traffic in IoT environment can be deducted from the existence of gSLAs on the HL-Gw for the corresponding LL-Gw. If there is no traffic in the IoT environment, there is no need to send the beacons to the nodes. After sending the beacon, the LL-Gw should receive data from different nodes depending on the corresponding QoS CAPs of each node. In case of reception of new configurations resulting from added, removed or modified iSLAs, the LL-Gw updates its configuration values and sends a new beacon to the IoT nodes.
3.4.2. QoS Class Based Access for IoT Objects
We specify in Figure 10
the Finite State Machine that illustrates the QBAIoT process within an IoT object (i.e., a node). In state S0, an IoT object receives the LL-Gw gateway beacon specifying the configuration of BO, SO, and QoS CAPs. Based on its QoS Class, the IoT object configures its Object_CAPStart and Object_CAPEnd and then switches to state S1. At state S1, if the IoT object determines that its QoS CAP has not started yet (i.e., Current slot < Object_CAPStart), then it will remain in state S1 and waits for its QoS CAP in the current superframe. On the other hand, if the node determines that its QoS CAP had ended (i.e., Current slot > Object_CAPEnd), then it will remain in state S1 and waits for its QoS CAP in the next superframe after receiving a new beacon. Finally, if the node determines that its QoS CAP is effective (i.e., Object_CAPStart ≤ Current slot ≤ Object_CAPEnd), then it switches to state S2. At S2, an IoT object evaluates the remaining time in its QoS CAP in order to send a packet. If there is sufficient time, the node executes the CCA. An idle channel reduces the CW value. If CW is greater than 0, the CCA should be executed again, whereas a CW equal to 0, enables the node to send its data to the LL-Gw and to get back to state S1. Then, it waits for the beacon or tries to send another data packet.
On the other hand, if the channel is not idle, NB is compared to macMaxBackoffs. A value of NB greater than macMaxBackoffs leads to a MLME (MAC sublayer management entity) status set to “Channel Access Failure” and the node gets back again to state S1 where it waits for the beacon or tries to send another data packet. If NB is lower than macMaxBackoffs, the NB value will be incremented and CCA should be executed again while the node remains at state S2.
We present in Figure 11
our adaptation of the slotted CSMA/CA process for IoT objects implementing QBAIoT. After receiving the beacon frame, the node (i.e., IoT object) synchronize the superframe duration with the coordinator (i.e., LL-Gw) by setting the values of BO, SO, its QoS CAP duration and the different values of CSMA/CA process (e.g., CW, NB, BE). Upon the creation of a data packet to be sent to the coordinator, the node has to check whether the current slot of the superframe is in its QoS CAP duration. If the number of the current slot of the superframe is greater than the number of the last slot of the QoS CAP duration, the node should wait the QoS CAP duration in the next superframe as its QoS CAP had ended. If the number of the current slot of the superframe is less than the number of the first slot of the QoS CAP duration, the node should wait until the start of its QoS CAP duration in the actual Superframe. Whereas, if the current slot is greater or equal than the first slot of the QoS CAP and less or equal than the last slot of the QoS CAP, the current slot is in the QoS CAP duration of the node and the CSMA/CA process is executed. When the current slot of the superframe is in the QoS CAP duration of the node, the remaining time in the QoS CAP is tested. If there is no sufficient time to send the data and receive the acknowledgement, the node should wait until the next QoS CAP in the next superframe. If there is sufficient time, the node determines the boundary of the next backoff period (each slot is divided into several backoff periods) as any operation should start at the boundary of a backoff period and cannot start during a backoff period. Then, the node observes a delay (random value between 0 and (2BE
− 1)) before performing the first CCA test.
On one hand, if the channel is not idle, the NB value is incremented, CW value is reset to the initial value, and BE value allowing the computation of the delay is changed. If the NB value is greater than the maximum value, then a failure occurs. If NB value is greater than the maximum value, the process restarts from the beginning; the node check once again whether the current slot of the superframe is in its QoS CAP duration. In the other hand, if the first CCA indicated an idle channel, CW is decremented and another CCA is performed if the CW had not reached the 0 value yet. When the CW value is equal to 0, the node can send the data to the coordinator.
3.5. Self-Configuring QBAIoT
The existence of traffic on the network influences the chosen values for BO, SO and the slots configurations of the QoS CAPs as mentioned in Section 3.4
. The characteristics of the underlying IoT environment in terms of traffics types’ existence have an impact on the configurations of the different QoS CAPs. We specify in Table 1
different scenarios of traffic existence along with the corresponding slots configuration and BO/SO values. Table 1
represents a part of the knowledge base of our self-configuring QBAIoT method (see Figure 12
). In this context, we consider that QoS CAP1 is allocated to the QoS class with the highest priority in the IoT infrastructure, whereas QoS CAP4 is allocated to the QoS class with the lowest priority if there are four QoS classes in the considered IoT environment. real-time class (RTC) includes the traffic of RTMC and RTNMC classes, whereas non-real-time class (NRTC) includes the traffic of streaming and NRT classes. The priority of the different available IoT traffics in descendant order is as follows: RTMC, RTNMC, Streaming, NRT. For example, let us consider the existence of two traffics belonging to two QoS classes: 1 RTC and 1 NRTC. According to Table 1
, QoS CAP1 is allocated 12 slots and corresponds to the highest priority (i.e., RTC traffic) and QoS CAP2 is allocated four slots and corresponds to the NRTC traffic.
Based on the different gSLAs stored on the HL-Gw, the number of QoS classes within a LL-Gw can be deducted. Therefore, the corresponding slots configuration of the Superframe is retrieved by the HL-Gw thanks to the knowledge base of QBAIoT that considers different available scenarios. The different available configurations in the knowledge base are the initial configurations to be set on the LL-Gw. These initial configurations could be adapted according to QoS CAPs usage by IoT objects through a self-optimizing function. If the slots allocated to a specific QoS class are not used efficiently, the self-optimizing function allows reallocating unused slots to another QoS CAP in need of slots while serving the higher priority classes first. In case of changes occurrence concerning the existence of QoS classes (iSLAs removal or addition), an update of BO and SO values as well as slots configuration should be performed. The updated values of BO, SO, and slots configuration are communicated to the LL-Gw that sends an updated beacon at the BI to all IoT nodes. Considering the IoT environment changes in an autonomic manner through the detection of iSLAs evolution on the HL-Gw in order to adapt the beacon configurations corresponds to the QBAIoT self-configuring capability.
QBAIoT self-configuring process (i.e., MAPE-K control loop) is implemented on the HL-Gw and the LL-Gw of our proposed IoT architecture (see Figure 12
). The HL-Gw corresponds to the AM (autonomic manager) that enables four functionalities (i.e., monitor, analyze, plan, and execute) along with the knowledge base. The LL-Gw contains an effector interface that receives the configurations sent by the HL-Gw in order to update beacon’s information. The LL-Gw sensor interface is not used for the self-configuring capability but for a self-optimizing capability enabling slots usage optimization.
The HL-Gw monitors the changes of the IoT environment by considering the different gSLAs stored in the knowledge base. For each LL-Gw, the monitor function groups the corresponding gSLAs into different bundles. Each bundle is specific to a LL-Gw and includes all the gSLAs of the IoT services available through that LL-Gw. Consequently, the characteristics of the LL-Gw environment are available in the bundle. The analyze function counts the number of QoS classes (Nb_QoS_Classes) and counts the number of RTC (RT_Classes) in each bundle. The analyze function deducts also the number of NRTC (NRT_Classes). Then, the HL-Gw Plan function searches in the knowledge base the corresponding entry to the number of RTC and NRTC retrieved by the analyze function. Finally, the Execute function extracts the values from the knowledge base entry and sends them to the effector interface on the LL-Gw. The effector updates the configuration values to be sent in the beacon. This control loop is called at each time the IoT-SP makes changes concerning the IoT environment. If an iSLA is added, removed or modified, the self-configuring control loop is executed in order to adapt the IoT LL-Gw configuration according to IoT environment changes without human intervention.
shows the detailed self-configuring process deployed on the HL-Gw along with the different MAPE-K functions. The HL-Gw monitors the environment changes and updates the values of Nb_QoS_Classes and RT_Classes. When Nb_QoS_Classes is equal to zero, the IoT-SP has no gSLA concerning the LL-Gw. In this case, no QoS classes are available on the LL-Gw environment and there is no need for configurations. If Nb_QoS_Classes is equal to 1, a single QoS class exists within the LL-Gw environment, then BO and SO are set to 14, and the single QoS CAP that exists in the superframe is allocated the 16 slots. If there is more than a single QoS class, Nb_QoS_Classes is greater than 1 and RT_Classes is equal to 0 then there are two classes that are NRTC. Consequently, the BO and SO values are set to 3 and the Superframe includes two QoS CAPs. The first QoS CAP, corresponding to the streaming traffic, is allocated 13 slots. Whereas, the second QoS CAP, corresponding to the NRT traffic, is allocated 3 slots. If Nb_QoS_Classes is greater than 1 and RT_Classes is equal to or greater than 1 then a nested loop is to be browsed in order to allow the HL-Gw to choose the corresponding slots configuration for the considered IoT environment.
4. QBAIoT Performance Evaluation
We describe in the following the performance evaluation details of our proposed QoS based wireless access method as well as the additional self-configuring capability enhancement. We use OMNeT++ to implement and simulate our QBAIoT access method according to several scenarios in order to evaluate the performance of our proposal. To do so, we adapt an IEEE 802.15.4 model available for OMNeT++ [32
]. The adaptation consists not only in removing the CFP and inactive parts of the standard superframe but also in creating different QoS CAPs within the same superframe. We conduct various simulation scenarios grouped into different set of simulations. The simulations common parameters for all sets are specified in Table 2
To evaluate the performance of QBAIoT according to the specified scenarios in the different sets, we take into consideration the QoS parameters included in the iSLA specified in Section 3.3
. First, the average delay refers to the average time experienced by a generated packet from the IoT object to be received by the LL-Gw. It is computed by dividing the sum of received packets delays by the number of received packets. Then, the packet delivery ratio (PDR) evaluates the reliability degree achieved by the QBAIoT based sensing layer in terms of successful transmissions. It is computed by dividing the number of received packet by the number of generated packets.
In the first set of simulations, we consider seven different scenarios described in Table 3
that shows the number of objects per QoS class in each scenario with the corresponding slots configuration. For all scenarios, the objects data generation interval time is fixed to 0.25 s resulting in 400 generated packets for each object during the simulation. Scenarios 1 to 4 take into consideration objects that generate the data at the same time, whereas Scenarios 5 to 7 take into consideration objects that do not generate the data at the same time. The first scenario corresponds to an IoT e-health service with three RTMC nodes resulting in allocating the 16 slots to the three nodes. The second scenario corresponds to an IoT e-health service requiring three RTMC nodes along with three RTNMC nodes. Based on the knowledge base, nine slots are allocated to RTMC nodes, and seven to RTNMC nodes. The third scenario corresponds to nine nodes (three RTMC, three RTNMC, and three streaming) resulting in 7/6/3 respectively for the slots configuration. The last scenario corresponds to the existence of 12 nodes (3 of each QoS class) resulting in a slots configuration of 6/5/3/2.
, Figure 15
, Figure 16
and Figure 17
show the performance evaluation comparison between our QBAIoT approach and the IEEE 802.15.4 standard according to Scenarios 1, 2, 3 and 4 correspondingly. Figure 14
presents the delay and PDR evaluation corresponding to scenario 1 with only one QoS class traffic (RTMC). We can observe that for one QoS class, QBAIoT acts like the traditional slotted CSMA/CA as one QoS class is allocated the totality of the slots. Indeed, the obtained results in terms of average delay and PDR are very close for the two approaches. In our approach, we can observe that we have a difference of 7 ms resulting from testing if the current slot is in the QoS CAP, which is not necessary in the traditional approach.
The obtained results in Figure 15
show that for 2 QoS classes, QBAIoT ensures a better delay for RTMC and an identical delay for RTNMC comparing to the standard IEEE 802.15.4 access method. Allocating two more slots for RTMC compared to RTNMC results in 10 ms better average delay for this QoS class. For the PDR evaluation, QBAIoT ensures better values for RTMC (99%) and RTNMC (98%) than the standard approach (56% and 55%, respectively). Our approach enables these performance results in terms of PDR, as only objects of the corresponding QoS class can compete to access the channel during the slots of a QoS CAP. Thus, our class-based access will avoid collisions between different traffics generated by objects belonging to different QoS Classes.
shows the evaluation performance corresponding to Scenario 3. The obtained results shows a better delay, while using QBAIoT, for RTMC and RTNMC traffic compared to the standard. With our QoS based access method, seven slots are allocated to the RTMC traffic and six for RTNMC traffic, resulting in better delays: 33 ms less than the standard for RTMC and 16 ms less as for RTNMC. Similarly, we obtain with our approach a better PDR for this scenario, as the number of collisions is lower. Indeed, the PDR for the RTMC traffic with QBAIoT is equal to 98.5% whereas it is equal to 26% with the IEEE 802.15.4.
The obtained performance results in terms of PDR and delay corresponding to Scenario 4, where the LL-Gw configures four QoS classes, are illustrated in Figure 17
. In this scenario, we observe that QBAIoT enables better delays for RTMC (90 ms) and RTNMC (106 ms) traffics compared to the IEEE 802.15.4 standard access method (115 ms for RTMC and 123 ms for RTNMC). Moreover, we observe better PDR for all QoS classes (>96% for three classes) using our approach compared to the standard (<20% for all classes). Indeed, for the IEEE traditional approach, all QoS classes will be served similarly and in the same time, resulting in more collisions and approximatively four slots for each QoS class; whereas our QBAIoT access method enables different QoS CAPs to minimize collisions and configures RTMC with six slots and RTNMC with five slots in this scenario. Finally, we observe an important delay for non-real-time traffic due to the configuration of only two slots for this class, which is not sensitive to the QoS delay parameter. In the other hand, we obtain for NRT traffic a better PDR (26%) than the traditional approach (16%).
shows the average delay of RTMC and RTNMC packets for Scenarios 5 to 7. In these scenarios, we increment the number of objects per QoS CAP (i.e., per QoS class) while not sending data at the same time by the objects of the same class. This difference allows minimizing the number of possible collisions in each QoS CAP and therefore serving the packets faster. We can note that with four and five objects per QoS CAP (see Figure 18
), QBAIoT, using a single coordinator, is capable of delivering RTMC and RTNMC packets while respecting the real-time traffic requirements. In Scenario 7, where six objects per QoS CAP exist, QBAIoT with a single coordinator is not sufficient to respect the requirements of real-time traffics. In fact, with six objects or more per QoS CAP in the context of these simulations, the number of objects competing during each QoS CAPs induces an additional delay before serving the data packets. Thanks to our proposed IoT architecture, we are capable of coping with this problem by implementing a new QBAIoT LL-Gw (i.e., coordinator) in order to extend the capacity of the IoT environment and respect the requirements of an increasing number of QoS classes corresponding to the subscribed iSLAs.
The second set of simulations allows evaluating the self-configuring capability of our QoS based access method. Indeed, we evaluate the impact of providing different superframe slots configurations according to the characteristics of the IoT environment. Furthermore, self-configuring QBAIoT enables different beacon configurations for the same number of QoS classes according to the number of RTC classes.
For the second set of simulations, we use an IoT environment including three different QoS classes for the first two scenarios. Every QoS class includes three nodes with a data generation interval of 0.25 s per node. Different configurations are available in Table 1
depending on the number of RTC among the three QoS classes of the considered simulation environment. Consequently, two scenarios are presented. Scenario 1 corresponds to the existence of two RTC and one NRTC traffics, whereas Scenario 2 corresponds to the existence of one RTC and two NRTC traffics. In Figure 19
, we compare the average delay of each traffic corresponding to these two scenarios while using QBAIoT and the IEEE 802.15.4 slotted CSMA/CA. The obtained results show that QBAIoT offers better delays for QoS CAP1 and QoS CAP2 traffics, whereas, QoS CAP3 traffic (delay tolerant traffic: streaming or NRT traffic) experiences a more important delay. Indeed, in Scenario 1, 2 RTC traffics are available within the IoT environment. Therefore, the two traffics should observe a minimal delay while prioritizing QoS CAP1 traffic. The corresponding slots configuration offers an additional slot to QoS CAP1 and allows respecting the interactive characteristic of the two RTC real-time traffics (a delay of 69 ms for QoS CAP1 traffic and a delay of 70 ms delay for QoS CAP2). Scenario 2 includes a single RTC traffic. Consequently, the delay QoS parameter is not critical for QoS CAP2 and QoS CAP3. In this context, we provide QoS CAP1 with eight slots enabling to further minimize the corresponding delay. As a result, we obtain a delay of 58 ms for QoS CAP1 comparing to the 69 ms delay in Scenario 1. The obtained results show that QBAIoT performs better than the IEEE 802.15.4 standard thanks to specific configurations enabling achieving the requirements of different traffic types in various scenarios depending on the environment characteristics.
We consider a third scenario in the second set of simulations. In this context, the IoT environment contains four QoS classes initially. After a period of time, the IoT-SP deletes gSLAs from the HL-Gw due to the cancellation of two iSLAs and therefore, only two RTC traffics remain in the LL-Gw environment. Initially, every QoS class includes three nodes. After 15 s of the simulation beginning, the gSLA concerning the Streaming and NRT traffics are removed and their corresponding traffics are stopped.
We compare in Figure 20
the average delay while using or not QBAIoT self-configuring capability for the highly critical data (RTMC and RTNMC). In this scenario, without QBAIoT self-configuring capability, the HL-Gw is not able to change the initial configurations without human intervention. Consequently, the slots allocated to streaming and NRT traffics remain not used during every superframe after deleting the corresponding gSLAs. Thus, for each superframe, five slots are lost resulting in a usage of 68% (11/16 slots) of the superframe slots. The obtained results illustrated in Figure 20
show that, with a self-configuring QBAIoT enabling the usage of these lost slots due to environment changes, the delay of RTMC and RTNMC traffics are improved in a way to respond better to real-time traffic requirements. Furthermore, the QBAIoT self-configuring capability enhancement enables better superframe slots usage. Figure 21
shows the obtained results concerning the PDR performance parameter for RTMC and RTNMC traffics while using QBAIoT with and without self-configuring capability according to the same Scenario 3. We can notice that with the self-configuring capability, the slots of the streaming and NRT traffics are reallocated to the remaining QoS classes immediately. Consequently, the PDRs of RTMC and RTNMC traffics undergo a small improvement as more slots are allocated to their QoS classes.
After comparing the performance of QBAIoT with the standard slotted CSMA/CA according to multiple scenarios and evaluating the importance of the self-configuring capability, it is crucial to compare the performance of our proposed method with other QoS based access methods such as SDA-CSMA/CA [30
]. SDA-CSMA/CA and QBAIoT aims to offer a certain service level in an IEEE 802.15.4 environment using the slotted CSMA/CA process for accessing the channel. Each approach has its own parameters and is based on a certain configuration for BO/SO. For instance, SDA-CSMA/CA uses an SO equal to 7 and a BO equal to 8. The SDA-CSMA/CA approach does not depend on Superframe Duration, unlike QBAIoT where BO and SO are set to 2. For the comparison, we consider the same environment characteristics as for the simulations conducted for SDA-CSMA/CA. The latter is limited to three QoS classes, therefore we specify only RTMC, RTNMC, and streaming QoS classes when we compare QBAIoT to SDA-CSMA/CA. Concerning the slots configuration, we consider the 7/6/3 pattern. Finally, for the data generation interval, we use an interval equal to 0.25 s. The SDA-CSMA/CA and QBAIoT comparison is conducted while using two then three objects per QoS class. The results are shown in Figure 22
demonstrates that QBAIoT offers better delays for all QoS classes while considering two nodes per QoS class. Furthermore, when we consider three nodes per QoS class, the delay experienced by critical traffic (RTMC and RTNMC) is better while using QBAIoT compared to SDA-CSMA/CA. As for the streaming traffic, we observe a more important delay with QBAIoT due to the minimal slots allocation but without any QoS degradation because the delay QoS parameter is not critical for such traffic.