SDNC manages the resources of the edge, fog, and cloud layer and determines the appropriate layer for data storage and computing, based on the output of the fuzzy system. The edge layer includes the resources of all On-Board Units (OBUs) of the smart vehicles that are able to communicate with each other. The vehicles act not only as a relay node, but they also process and analyze the data by themselves and at the same time share their available resources with some vehicle that has a shortage of resources (hereinafter will be referred to as the vehicle). The fog layer consists of the RSUs, RSU Controllers (RSUCs), Base Stations (BSs), and fog servers, which are ideally only a few hops away from the vehicles. It offers more resource capabilities, compared to the edge layer, while still providing computing in real-time. Whereas the cloud layer offers abundant storage and computing facilities, located far away at the cloud data centers.
We consider this architecture from a bottom-up approach, which implies that the edge layer is the first layer considered, based on the available connections and service requirements. If the application requirements are not fulfilled or there are no or only very few available connections, then the fog layer is the layer taken into consideration. For instance, safety applications are suitable for either edge layer or fog layer, as both these layers support real-time processing and high QoS. The cloud layer is used to process applications that are delay tolerant and require long-term analytics. Through this approach, all network resources are utilized effectively and massive traffic flow in the core network is avoided.
IFS-CMR is implemented in the SDNC and the vehicles which are equipped with an SDN module. In case a vehicle does not have an SDN module, it sends the information to SDNC which computes the needed information and sends back its decision.
In the next subsections, we give details of the composition of the proposed approach and describe the input and output parameters of each subsystem. In addition, we present the data gathering and communication module which is integrated into the vehicles and explain the FL Controllers (FLCs) of the system.
3.1. Data Gathering and Communication Module
The vehicles are equipped with various sensors (lidar, radar, ultrasonic, camera, etc.) which are placed internally and externally to acquire information about the vehicle itself (its speed, direction, steering wheel movements, tire slip, distance between the lane and other nearby vehicles, and so forth) and the condition of roads (congested roads, inadequate traffic signs, potholes, ice patches, or other hazards); a wireless transceiver device which supports different wireless technologies that enable communications with other entities; a GPS device that provides precise information about location; and an OBU which controls the communication of vehicle with other entities and offers computing, storage, and networking facilities [
44]. We have included all these components in the data gathering and communication module, as shown in
Figure 3 (also referred to separately as data gathering module and communication module in
Figure 1).
Once the data is sensed and processed, the vehicles then share with one another important information through beacon messages. They broadcast these beacons periodically to other vehicles via V2V communication links to increase cooperative awareness between them. The beacon messages are critical for our approach as well. Once the vehicles receive them, they extract the information they need, which for IFS-CMR is about their neighbors’ geographic position, speed, direction, transmission power, available storage, available computing power, etc. Then, IFS-CMR makes the necessary calculations to update the current condition of all the input parameters.
3.2. IFS-CMR Parameters
The parameters of IFS-CMR are described in detail in the following.
Link Latency (LL): Latency is a strong requirement in VANETs. Many applications, especially those related to safety, must run in real-time and the network must provide a very low latency despite the rapid and high topology changes. Therefore, the time it takes the first bit to get from the sender to the destination is crucial in providing high QoS.
Radio Interference (RI): Radio Interference indicates the unwanted signals that come from transmissions of adjacent vehicles and disrupt the reception of information. These signals can cause problems from low data speed transmissions to even complete loss of information.
Effective Reliability (ER): We define effective reliability as the capacity of the network to successfully deliver messages to its destination. There are many factors that influence ER that include the bandwidth of transmission medium, number of collisions, and buffer size, among others.
Update Information for Vehicle Position (UIVP): It is necessary for vehicles to have the coordinates of other surrounding vehicles in order to detect dangerous situations or to monitor traffic. However, too many packets occupy more bandwidth, whereas few packets cannot accurately discover the position of neighboring vehicles.
Quality of Service (QoS): Each application has different requirements in terms of latency, bandwidth, throughput, and so on. Safety applications, for example, require real-time communications over reliable links. The latency constraints for such applications are in the range of a few milliseconds [
45,
46]. However, satisfying QoS requirements at all times is not a straightforward task given the highly dynamic topology and interference on these networks.
Available Computing Power (ACP): Recent VANET applications require significant computational resources and real-time processing. The intelligent vehicles in the new generation of VANETs are capable of handling some of these applications. Vehicles use their computing power to run their own applications, but they can also allocate some of it for other vehicles to help them in case they need additional computing power to complete certain tasks. When vehicles are willing to share their resources, they let their neighbors know by sending them information about the amount they want to share. In other words, they decide the number of physical processor cores and the amount of memory that other vehicles can use.
Predicted Contact Duration (PCD): In a V2V communication, the duration of the communication session is important since it determines the amount of data to be exchanged and the services that can be performed. A vehicle in need of additional resources (
the vehicle) will have to set up virtual machines on the neighbors that are willing to lend their resources; therefore, the contact duration becomes even more important since much more time is needed to accomplish these tasks than just performing a data exchange. Since the vehicles change their direction or speed, we can only make a prediction of their contact duration based on the value of the parameters at the time when the beacon message was transmitted (for more accuracy, the PCD is updated each time a new beacon message from that neighbor is received). To calculate the PCD between
the vehicle and a neighbor vehicle
i (see
Figure 4 for illustration), we first calculate the relative speed between these two vehicles using the law of cosines, as given in Equation (1).
where
V is the speed of
the vehicle,
is the speed of neighbor
i, and
is the angle between their directions. Then, we use the law of cosines once again to calculate the PCD, as given in Equation (2).
where
denotes the initial distance between the two vehicles,
CR is the communication range,
is the angle between the direction of
the vehicle and
imaginary line; whereas
is calculated with the Equation (3), which is derived from the law of sines.
We posit that when two vehicles are getting farther from each other from different directions, their directions form a positive angle, whereas when the vehicles are getting closer, is negative.
Available Storage (AS): Since vehicles generate and receive enormous amounts of data, their storage might be insufficient despite their large storage resources. If the vehicle needs to use also the storage of the neighbors, that should be large enough to allow the vehicle to run the virtual machine. This storage is used also to store data after completing specific tasks of all the tasks these neighbors are asked to accomplish.
Neighbor i Processing Capability (NiPC): Describes the capability of a vehicle to help another vehicle that lacks the appropriate resources to accomplish certain tasks. The values of this parameter range between 0 and 1, with the value 0 implying that the neighbor cannot help at all and 1 that the neighbor is in the best condition to help out the vehicle.
Average Processing Capability per Neighbor Vehicle (APCpNV): This parameter is the average of the Processing Capability (PC) of all neighboring vehicles within the vehicle’s communication range. It is an important parameter that represents the capability of the edge layer, and it is calculated as the sum of the PC of each neighbor vehicle divided by the number of neighboring vehicles.
Number of Neighboring Vehicles (NNV): This parameter changes continuously due to the vehicles moving out of the vehicle’s communication range and the ones that appear. Vehicles traveling at the opposite direction lead to even more frequent changes. Since the bigger the angle between the directions, the bigger the distance created between the vehicles, we consider only the neighbors whose directions with the direction of the vehicle create angles that are smaller than 90°. Vehicles traveling in directions that create bigger angles move out of the communication range very quickly, making it impossible for the vehicle to use their resources.
Time Sensitivity (TS): Different applications have different requirements in terms of latency. For instance, safety applications require a strict latency to be guaranteed, ideally <1 ms, whereas comfort and entertainment applications can tolerate latencies up to some seconds and are considered delay-tolerant [
45,
46]. System updates and the data collected for long-term analytics can tolerate even longer latencies, thus for such applications, the latency is not considered a requirement at all.
Data Complexity (DC): There are many factors that dictate the data complexity, and the volume is only one of them. Even a single application might use data that differ in type and structure, not to mention that they may come from many disparate sources (e.g., sensors, cameras, radar, lidar). Besides, there are different kinds of applications that include not only VANET applications, as in the Big Data era vehicles can also be used to compute data non-related to VANETs. However, not all the data need considerable processing as some of them are in the form of small messages that are used to inform the vehicles for particular situations.
Layer Selection Decision (LSD): The output parameter values, which are always between 0 and 1, denote three decisions—the interval [0, 0.3] indicates that the vehicle can use the edge layer resources, the values in the interval (0.3, 0.7) specify that the layer to be used is the fog layer, whereas the values in [0.7, 1] specify the cloud layer as the most appropriate layer to run their applications.
3.3. Description of IFS-CMR Subsystems
The input parameters of each subsystem of IFS-CMR do not correlate to one another, leading to an NP-hard problem. Problems with three or more uncorrelated parameters are classified as NP-hard because finding a mathematical model that can calculate an output in polynomial-time is practically impossible. Heuristic or meta-heuristic approaches are proven to provide adequate solutions for these kinds of problems, but each method has a limited scope to which it can be applied. For instance, genetic algorithms give good solutions for optimization and allocation problems. Neural networks can be applied to recognition problems and rule learning. FL, on the other hand, can be used to provide a solution for decision-making and control problems in real-time, especially when the system contends with high levels of imprecision and uncertainty [
47,
48,
49,
50,
51,
52].
Making real-time decisions while dealing with imprecision and uncertainty is the advantage of IFS-CMR. The characteristics of the network created between vehicles change continually and rapidly; therefore, the resources must be managed in real-time. Moreover, because of the rapid changes, the decision is reached in presence of much imprecision.
IFS-CMR is comprised of three integrated subsystems (FS-AQoS, FS-ANVPC, and FS-CFELS), each controlled by its respective FLC. Each subsystem has a key role in the system. They have their own input parameters and their output serves the subsystem that follows. The structure of IFS-CMR is shown in
Figure 3. The way we have built IFS-CMR has allowed us to continually improve it by discovering the implementation flaws (contrary to many AI systems, which behave as black boxes that do not provide any feedback how they reach their decision, and consequently are difficult to improve).
The term sets for the parameters of each subsystem are shown in
Table 1,
Table 2 and
Table 3. The parameters are fuzzified using the membership functions shown in
Figure 5,
Figure 6 and
Figure 7. The number of terms for each parameter and the characteristics of each membership function are determined through the experience gained by running many simulations. From our experience, using less than three linguistic terms for an input parameter has the risk of inefficient control and making poor decisions, whereas using more leads to redundancies and increased complexity. The same holds true for the overlap of membership functions. Less overlap results in poor decisions, more overlap brings redundancies. Regarding the shape, we use triangular and trapezoidal membership functions as they are the most suitable ones for real-time operation.
In
Table 4,
Table 5 and
Table 6, we show the Fuzzy Rule Base (FRB) of FS-AQoS, FS-ANVPC, and FS-CFELS, respectively. The FRB forms a fuzzy set of dimensions
, where
is the number of terms on
and
n is the number of input parameters. Therefore, since each subsystem has four input parameters with three linguistic terms, each FRB consists of 81 rules. The control rules have the form: IF “conditions” THEN “control action”. For instance, for FS-AQoS, for Rule 20: “IF LL is Lo, RI is Ha, ER is Nef and UIVP is Mo, THEN QoS is Md”.