SQoS(i, j) is based on the QoS parameters, that is the bandwidth, the loss rate, the delay and the jitter. The importance of these parameters depends on the application that is running. It is expressed by attributing weightings to different parameters.
The QoS SQoS(i, j) score is given by equation [1.7]:
where
– Bi is the bandwidth available via the channel i;
– bj is the minimal bandwidth required by the application j;
– Ei is the loss rate via the channel i;
– ej is the maximum loss rate authorized by the application j;
– Di is the average delay in the channel i;
– dj is the maximum delay supported by the application j;
– Gi is the average jitter in the channel i;
– gj is the maximum jitter supported by the application j;
– vi is the maximum speed authorized on the channel i (vi depends on the network coverage);
– V is the speed of the IoT object;
– αB is the weight of the bandwidth;
– αD is the weight of the delay;
– αG is the weight of jitter;
– αE is the weight of the loss rate;
– xi⊗yj = 1 if xi > yi, otherwise 0;
– Ai is the availability probability of the channel at the period t + 1.
The formula used to calculate the application’s QoS score j makes it possible to distinguish the different classes of service by adjusting the threshold values (bj, dj, gi, ej) and the weight criteria (αB, αD, αG, αE).
1.4.2.4. Stage 4: attribution of weight and calculating the final score
This last stage will be responsible for calculating the total score ST(i, j) for each candidate channel by weight the energy scores and the QoS. The weightings attributed to both scores will make it possible to select the IoT application domain (e.g. VANET and e-health).
This stage will therefore calculate the total score ST(i, j) for each candidate channel depending on the weight attributed to each aspect. The weight attribution for the criteria should reflect the importance of each decision criteria depending on the application context or, depending on the case, the preferences of the user (0 ≤ δ ≤ 1).
The total score ST(i, j) is given by equation [1.8]:
The selected channel will be the candidate with the highest total score. Finally, this information will be registered in the database for future use when a similar case occurs.
1.4.3. Performances evaluation
The multicriteria decision-making module that we suggest should be useful in different IoT contexts, particularly in M-RAN and CRN contexts. To illustrate the use of the retained approach in these two contexts and evaluate performances in each of them, we consider, in this section, two significant IoT use-cases: VANET and CR-VANET (Cognitive Radio VANET). In a VANET network, the On-Board Unit (OBU) is installed in the vehicle and includes a wireless transmitter receiver and various sensors, whereas a Road-Side Unit (RSU) is deployed in strategic locations along the route to facilitate communication between the vehicle and the infrastructure (V2I: Vehicle to Infrastructure). In V2I, information is exchanged between the vehicle and the RSU, or potentially a cellular network. VANET applications can be divided into three main categories (Javed et al. 2014): road safety (collision detection, cooperative driving, etc.), traffic management (route guidance, traffic light synchronization, etc.) and user infotainment (Web, streaming audio/video, etc.). Safety applications do not tolerate a transmission delay higher than 0.5 s (Javed et al. 2014), whereas traffic management applications are less demanding, with a tolerated latency between 0.1 and 1 s (Javed et al. 2014). As for infotainment applications, they generally accept greater latency, in order of 1–5 s. Nevertheless, some applications of this type, like multiplayer games, may require lower latencies of 0.1–1 s (Javed et al. 2014).
Based on the access networks detected or the channel available, and depending on the QoS requirements of the VANET applications, the suggested multicriteria decision-making module will select the best access network or radio channel available for a specific case. To do this, the utility function will calculate the scores of different candidate networks/radio channels to select the one that has the highest score.
Since we are considering combustion rather than electrical vehicles, we suppose that there is no energy constraint. Thus, the scores calculated from the different candidate channels are based only on the QoS parameters.
To evaluate the approach retained, we consider two representative types of transmission: multimedia emergency notification and infotainment applications, especially restaurant reservation. Table 1.1 summarizes the QoS requirements of these services.
Table 1.1. Some vehicular network services and the corresponding QoS parameters
| Type of service | Relevance of QoS parameters |
| Multimedia emergency notification | Latency (+++), bandwidth (+++) and packet loss (+) |
| Restaurant reservation | Latency (+), bandwidth (+) and packet loss (+) |
Table 1.2 shows the estimation of the weight of the data flow, the delay and the packet loss rate for services considered in the vehicle networks. These weightings are based on the importance of each parameter in Table 1.2.
Table 1.2. Weight estimation for services considered in vehicular networks
| Type of service | Weight estimation | ||
| Delay | BP | PLR | |
| Multimedia emergency notification | 0.43 | 0.43 | 0.14 |
| Restaurant reservation | 0.33 | 0.33 | 0.33 |