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

attribute specifying the cost of the IoT service and the methodology for managing violations and resulting penalties through thresholds and monitoring intervals for each quantitative QoS parameter.

      1.6.2. The QBAIoT process in the IoT

      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.

      1.6.2.1. QBAIoT gateways

      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.

Schematic illustration of an algorithm for the QBAIoT access method at the IoT object level.

      Figure 1.6. Algorithm for the QBAIoT access method at the loT object level

      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