1.6.2. The QBAIoT process in the IoT
In order to guarantee the QoS parameters negotiated in the iSLA service level agreement, we propose a new QoS mechanism for the lowest layer of the IoT architecture, namely the sensing layer. We thus specify a wireless access method called QBAIoT (QoS Based Access method for IoT) (Khalil et al. 2018). This method enables the communication between the IoT objects and the LL-Gw, while adapting the superframe structure of the IEEE 802.15.4 standard and the slotted CSMA/CA mechanism. The adaptation allows the differentiation of traffic in order to meet the QoS requirements of each class.
The QBAIoT method takes into account up to four QoS classes as defined in the iSLA’s qualitative parameters (RTMC, RTNMC, Streaming and NRT). Real-time traffic (RTMC and RTNMC) is very sensitive to delay, Streaming traffic is sensitive to jitter (that is, variation of delays), while NRT traffic is a QoS class that has no QoS constraints. To adapt the structure of the superframe, QBAIoT replaces the single Contention Access Period (CAP), common to all objects, and also replaces the non-contention period (CFP: Contention Free Period) of the classic IEEE 802.15.4 superframe by novel QoS CAPs. Each QoS CAP is specific to a QoS class. Thus, the adapted QBAIoT superframe can contain up to four QoS CAPs. The number of QoS CAPs configured in a LL-Gw depends on the number of QoS classes defined in the iSLA for this gateway. In addition, the inactive part of the classic superframe is eliminated in the context of QBAIoT. This deletion leads to shorter timeframes and enhances the performance of traffic in the Real-Time category. On the other hand, the number of slots available in the superframe is fixed at 16 and the duration of each slot depends on the superframe duration (SD). The SD is calculated based on the value of the Superframe Order (SO). The Beacon Order (BO) is used to calculate the interval for sending beacon frames (Beacon Interval [BI]). In QBAIoT, BO and SO are always equivalent as the inactive period is deleted.
During each QoS CAP in the QBAIoT superframe, only the objects that generate traffic belonging to the corresponding QoS class can compete for access to shared support. Each QoS CAP is assigned a number of slots among the 16 available in the superframe. The configuration of the slots and of the BO/SO values depends on the number of existing QoS classes in the IoT environment under consideration and, in particular, the number of real-time QoS classes. If only one class exists, the classic IEEE 802.15.4 superframe structure will be used, but with no CFP period and no inactive period, as only one QoS CAP exists. In addition, in this case, the values of the BO and SO are set to 14 to minimize the number of beacons sent in the IoT environment. When several QoS classes exist, the BO and SO are initialized to a value of 2 if there is at least one real-time QoS class (RTMC or RTNMC), and to a value of 3 if there is no real-time QoS class. The QBAIoT method is implemented on the LL-Gw (acting as coordinator) as well as on the IoT objects of the sensing layer. Figure 1.4 shows a comparison between the structure of the standard IEEE 802.15.4 and QBAIoT superframes.
Figure 1.4. Comparison of the structure of the IEEE 802.15.4 and the QBAIoT superframes. For a color version of this figure, see www.iste.co.uk/mbarek/service.zip
1.6.2.1. QBAIoT gateways
For each BI, the LL-Gw that implements QBAIoT sends a beacon frame containing the information about the BO and SO values as well as the values for the first and last slot of each QoS CAP. These values are used by the IoT objects in the sensing layer to determine how long they are allowed to be in contention to access the channel. The QBAIoT gateway chooses an initial configuration for the superframe according to the number and types of QoS classes that exist in its environment. Following the dispatch of a beacon frame, the QBAIoT gateway begins to receive data from different objects during the corresponding QoS CAPs. The schema for the QBAIoT algorithm deployed for the gateway is illustrated in Figure 1.5.
A QBAIoT gateway also has self-management functionalities. Indeed, a self-configuring function allows the gateway to adapt the configuration of the different QoS CAPs based on the existing number of QoS classes in its environment. This function also makes it possible to apply a reconfiguration of these QoS-based contention periods following changes made at the iSLA level regarding the environment of this gateway. On the other hand, a self-optimizing function performed by QBAIoT overcomes the problem of unused slots by IoT objects in a QoS CAP. This function is provided by a slot reallocation mechanism covering the entire superframe. The two functions, self-configuring and self-optimizing, make it possible to improve the QBAIoT performance in an IoT environment.
Figure 1.5. Algorithm for the QBAIoT access method at the gateway level
1.6.2.2. QBAIoT objects
Figure 1.6 depicts the schema for the QBAIoT algorithm used by IoT objects, taking into account the slotted CSMA/CA method.
Figure 1.6. Algorithm for the QBAIoT access method at the loT object level
All objects in the environment of the QBAIoT gateway receive the beacon frame. Depending on the QoS class to which they belong, each object determines the QoS CAP during which it can attempt to access the shared channel. When an object generates data, it must test whether it has the right to attempt to send its traffic. If the QoS CAP corresponding to the IoT object in the superframe has not yet started, then it waits for the start of its QoS CAP and then begins competing with other objects in its QoS class to send its data according to the slotted CSMA/CA. On the other hand, if the QoS CAP of the object in the current superframe has elapsed, then it waits for the corresponding QoS CAP in the next superframe. Otherwise, the object has the right to enter into contention with the other objects of its class for access to the channel according to the slotted CSMA/CA mechanism, as its QoS CAP is in progress.
1.6.3. QBAIoT performance evaluation
1.6.3.1. Simulation environment
As part of the QBAIoT performance evaluation, we use the OMNeT++ network simulator by adapting an IEEE 802.15.4 model available for OMNeT ++ (Kirsche 2018). Adaptation consists of not only deleting the non-contention period (CFP) and the inactive part of the standard superframe but also creating different QoS CAPs within a single superframe. Different simulation scenarios are carried out by varying the number of QoS classes in the considered IoT environment. Table 1.1 describes the configuration and characteristics of the different simulation scenarios in terms of the number of existing QoS classes, the number of objects per class and the distribution of slots by class.
Table 1.1. Parameters for the QBAIoT simulation scenarios
| RTMC objects | RTNMC objects | Streaming objects | NRT objects | Configuration of the slots | |
| Scenario 1 | 3 | 0 | 0 | 0 |