communications Path Finding in Vehicular Networks (VPFVN):

Compte tenu des informations sur les emplacements des serveurs MEC, les emplacements et la vitesse des véhicules, et les situations des canaux sans fil des réseaux véhiculaires, le problème VPFVN est de trouver s’il existe des voies de communication V2V entre les véhicules et les serveurs MEC, et d’en choisir une voie de communication V2V afin de minimiser le délai de transmission des données mis en marche.
Soit v0, y désignant le nœud de départ et nœud de fin du chemin de communication V2V s’il existe, respectivement. P = {v1, v2, …, vs} est l’ensemble des véhicules utilisés pour les communications V2V de v0 à y. À cause de la fonction de gestion centrale de l’architecture SDN, le contrôleur SDN peut connaître la distance entre v0 et les véhicules autour de lui.
S’il n’y a pas de véhicule dans la couverture sans fil de v0, le résultat est qu’il n’y a pas de chemin de communication V2V entre v0 et y. Sinon, le contrôleur SDN compare les taux de transmission de liaison ascendante de données entre v0 et les véhicules qui l’entourent, et choisi un véhicule v1 pour atteindre un débit de transmission de données maximal. Après que, le contrôleur SDN répète les étapes ci-dessus pour trouver le prochain nœud du nœud précédent jusqu’à ce que nous atteignions le nœud final y. Soit Si l’ensemble des véhicules autour de vi. Les détails de ceci sont brièvement donnés dans l’algorithme 1.
Après que nous sachions comment trouver un V2V chemin de communication, le prochain problème à résoudre est comment obtenir un profil de décision de déchargement afin que le délai total de traitement des véhicules soit minimum. Nous présenterons trois solutions différentes à ce problème. Les deux premiers schémas sont basés sur la théorie des jeux. Dans nos schémas, chaque véhicule choisit la meilleure décision de déchargement, ce qui rend le délai de traitement de sa tâche minimisé dans chaque créneau de décision, selon le profil de décision de déchargement des autres véhicules.

Game Theory Based Nearest Task Offloading Algorithm (GTNOA).

Pour l’algorithme 2, nous adoptons le principe de proximité, qui signifie que les véhicules sélectionnent les serveurs MEC les plus proches d’eux. Dans ce cas, la valeur de λi peut être réduite à λi ∈ {0 ,1, – 1}, où λ i = 1 signifie que le véhicule- i décide de se décharger de sa tâche au serveur MEC le plus proche.
Predictive Game Theory-based Task Offloading Algorithm (PGTOA).
De plus, nous proposons également algorithme prédictif de déchargement des tâches basé sur la théorie des jeux (PGTOA), dans lequel nous estimons les emplacements des véhicules lorsque leurs tâches sont terminées en prédisant le temps de traitement de leurs tâches, afin que nous puissions exécuter les tâches aux serveurs MEC que les véhicules arriveront. On a aussi λi ∈ {0, 1, -1} dans cet algorithme. Puisque l’algorithme 2 et PGTOA adopte des stratégies de théorie des jeux, et ont la même structure, nous ne donnons ici que les détails de l’algorithme 2.
Les capacités de calcul des serveurs MEC diminuent avec le nombre de véhicules qui choisissent pour décharger leurs tâches de calcul vers les serveurs MEC augmente. Ce phénomène conduit à une augmentation du retard de traitement des tâches. Par conséquent, il est nécessaire de prendre l’équilibrage de charge des ressources de calcul au niveau des serveurs MEC en compte, et nous proposons en outre un algorithme d’équilibrage de charge approximative de déchargement des tâches pour résoudre le problème de minimisation du délai de traitement des taches.

An Approximate Load Balancing Task Offloading Algorithm (ALBOA).

Spécifiquement, nous supposons que tous les serveurs MEC sont des serveurs optionnels auxquels véhicule – je peux décharger sa tâche de calcul, puis déterminer quel serveur MEC choisir en tenant
compte du compromis entre l’heure d’exécution de la tâche et l’heure de transmission des données. Dans ce cas, on a λi = {0, 1, 2, 3, …, M, – 1}. Soit Clocal, Cj mej (1 ≤ j ≤ M) et Clocal désignent les
ensembles de véhicules qui décide d’exécuter leurs tâches de calcul localement, les décharger au serveur MEC connecté à RSU- j et sur le serveur cloud distant, respectivement. Nous calculons d’abord le traitement des retards de toutes les tâches via tous les décisions de déchargements possibles et abandonner les tâches dont les délais de traitement dépassent leurs délais maximaux admissibles. Après cela, nous attribuons les tâches qui ne peuvent pas être exécutées localement sur Cj mej et Clocal, en comparant les délais de traitement via les différentes décisions de déchargements. Enfin, nous mettons à jour de manière itérative les interférences sans fil du réseau et déterminer les décisions de déchargement des tâches restantes. Les détails de cet algorithme sont donnés dans Algorithme 3.

Résultats

Figure 15 : Comparaisons de l’équilibrage de charge entre les serveurs MEC en adoptant séparément trois algorithmes, c’est-à-dire GTNOA, PGTOA et ALBOA
La figure 15 peut être divisée en trois parties représentant les performances des trois schémas, où chaque partie contient l’état de charge de tous les serveurs MEC. Les nombres sur l’histogramme désignent les étiquettes numérotées du serveurs MEC. À partir de la figure, nous pouvons conclure que la charge de chaque serveur MEC n’est pas uniforme lorsque nous adoptons GTNOA et PGTOA. Par exemple, concernant PGTOA, la capacité de calcul du serveur MEC-4 et du serveur MEC-6 est occupée par près de 90%, alors que la capacité de calcul du serveur MEC-7 est utilisé seulement environ 10%. Ce phénomène provoquera la congestion informatique de certains serveurs MEC sont alors que d‟autres sont inactif, ce qui entraîne un gaspillage de ressources de calcul. De toute évidence, le même problème se produit également lorsque nous adoptons GTNOA. Par conséquent, il est nécessaire d’envisager un équilibrage de charge dans les réseaux véhiculaires. L’ensemble final des résultats expérimentaux de la figure 15 montre les performances supérieures d’ALBOA dans l’équilibrage de charge, c’est-à-dire les ressources de calcul de chaque serveur MEC sont également utilisées.
Figure 16 : Comparaisons du délai de traitement total en adoptant séparément trois différentes stratégies de déchargement, c’est-à-dire ALBOA, ALBOA sans déchargement cloud et exécuter toutes les tâches localement, car le nombre de tâches de calcul chang
La figure 16 illustre les comparaisons du délai de traitement total en adoptant séparément trois stratégies de déchargement différentes, c’est-à-dire ALBOA, ALBOA sans déchargement cloud et exécution de tout tâches localement, car le nombre de tâches de calcul change de 20 à 120. On constate que les résultats obtenus par ALBOA sans déchargement cloud sont beaucoup moins que ceux qui exécutent tout tâches localement, ce qui démontre que le déchargement MEC a un impact considérable sur la réduction du délai de traitement des tâches de calcul des véhicules.

Présentation de la deuxième solution

Les applications IoT peuvent choisir des nœuds de brouillard ou de cloud computing pour répondre aux besoins en ressources, et l’équilibrage de charge est l’un des facteurs clés pour atteindre l’efficacité des ressources et éviter les goulots d’étranglement, la surcharge et la faible charge. Cependant, c’est toujours un défi pour réaliser l’équilibre de charge pour les nœuds de calcul dans l’environnement de brouillard lors de l’exécution des applications IoT. En vue de ce défi, une méthode d’allocation dynamique des ressources, nommée DRAM, pour l’équilibrage de charge en environnement de brouillard a été proposée. Cette méthode vise à atteindre un équilibrage de charge élevé pour tous les types de nœuds de calcul dans le brouillard et les plates-formes cloud.

Fonctionnement de l’architecture et les solutions

Notre méthode se compose de quatre étapes, c’est-à-dire partition de service de brouillard, détection d’espace libre pour les nœuds de calcul, allocation de ressources statiques pour le service de brouillard sous-ensemble, et l’allocation globale des ressources basée sur l’équilibre de la charge. Dans cette méthode, l’étape 1 est la procédure de prétraitement, l’étape 2 est utilisée pour détecter l’utilisation des ressources pour les étapes 3 et 4, et l’étape 3 est conçue pour les ressources statiques d‟allocation pour les services de brouillard dans le même sous-ensemble et il fournit les principales stratégies de fourniture de ressources pour l’étape 4. Enfin, l’étape 4 est une méthode d’allocation globale des ressources pour réaliser l‟équilibre de charge dynamique.
Etape 1 : Partition de service de brouillard
Les besoins en ressources des services de brouillard dans le même ensemble ont un temps de réponse de ressource différent. Pour réaliser efficacement allocation des ressources pour les services, les services de brouillard dans le même ensemble doit être partitionné en plusieurs sous-ensembles selon l’heure de début d’occupation des unités de ressources des nœuds de calcul. Ensuite, nous pouvons allouer des unités de ressources pour les services de brouillard dans le même ensemble pour atteindre un équilibrage de charge élevé.
Algorithme 1 : acquisition de sous-ensemble de service de brouillard
L’algorithme 1 spécifie le processus du sous-ensemble de services de brouillard acquisition. Dans l’algorithme 1, l’entrée est la ressource requise-des applications IoT, c’est-à-dire, et le résultat est le Service partitionné de brouillard. Nous traversons tous les services de brouillard (Ligne (1)), et les services sont mis dans différents ensembles selon le type de ressource demandé (lignes (1) à (6)), puis les services de brouillard sont placés dans différents ensembles de services. Ensuite, l’ensemble est divisé en plusieurs sous-ensembles, selon le début requis temps (lignes (8) à (17)).
Etape 2 : Détection d’espace de réserve pour les nœuds de calcul
Les services brouillard doivent être mis sur les nœuds informatiques ; ainsi, les nœuds informatiques avec de l‟espace libre doivent être identifiés. Pour tous les nœuds de calcul, les registres d’allocation sont utilisés pour surveiller l‟utilisation des ressources de tous les nœuds informatiques dans le brouillard et le nuage.
L’espace disponible du nœud de calcul pourrait être détecté à partir de l’analyse des registres d’occupation. Dans ces registres, si l’heure de début de l’occupation est inférieure à l’heure l‟instant de temps statistique pour vérifier la fin de l’occupation de temps est au-dessus du temps statistique, les unités de ressources pertinentes combinés dans les registres d‟occupations peuvent être obtenus. Avec ces unités de ressources acquises et la capacité en ressources de l’espace disponible pourrait enfin être détecté.
Algorithme 2 : détection d’espace de réserve pour les nœuds de calcul
L’algorithme 2 spécifie l’idée clé de la détection d’espace libre pour le calcul des nœuds. Dans l’algorithme 2, l’entrée et la sortie sont les registres d’occupation du nœud de calcul et l’espace disponible
Etape 3 : Allocation de ressources statiques pour le sous-ensemble de service de brouillard
Dans cette partie, nous définissons les registres d’allocation de ressources pour réserver l’historique d’affectation des ressources pour les services de brouillard.
Pour réaliser l’équilibrage de charge des nœuds de calcul, nous essayons d’atteindre une utilisation élevée des ressources du nœud l’informatique utilisé. Avant l’allocation des ressources, les services de brouillard sont triés par ordre décroissant du montant de la ressource demandée. Le service avec plus d‟unités de ressource nécessaire sera traité en premier. Et il choisit le nœud de calcul avec le moins et suffisamment d’espace disponible pour héberger le service.