Le modèle permet de montrer deux résultats principaux. D’abord, en termes de faisabilité, l’acheminement géographique offre des avantages en termes d’uti- lisation mémoire pour les topologies denses et/ou larges. Ceci est dû à la localité de la stratégie d’acheminement, qui ne demande que de connaître des informa- tions locales (i.e., la position des voisins) plutôt que des informations globales (un prochain saut pour chaque nom supporté sur le réseau IoT). De plus, l’ache- minement géographique offre des avantages pour les réseaux très dynamique grâce à son trafic de contrôle local moins couteux que l’inondation – même opti- misée avec MPR – du réseau de capteurs sans-fil. Pour les réseaux plus stables, l’état additionnel dans le paquet nécessaire pour GPSR rend l’acheminement géographique marginalement plus couteux en énergie que MPR.
B.3
Contrôle d’admission pour applications à temps
de réponse contraint
Dans un second temps, le problème du contrôle d’admission dans des plate- formes de type Fog est traité. En effet, pour être utiles, les données produites par les capteurs doivent pouvoir être traitées en temps limité. Dans ce but, le Fog a été inventé [17]. Il s’agit d’une plateforme de calcul et de stockage distribué se situant au bord du réseau, proche dans l’endroit où les données IoT sont pro- duites et consommées afin de réduire la latence. Néanmoins, et en comparaison avec le Cloud, le Fog manque d’élasticité. Il est donc important de contrôler la charge du Fog pour garantir le temps de réponse de l’application. En particulier, cette section contient une proposition de contrôle d’admission de requêtes dans un nœud de type Fog, conçue pour optimiser l’utilisation des ressources sous contrainte de temps de réponse.
B.3.1
Contrôle d’admission dans le Fog et modélisation
La situation considérée est la suivante : un utilisateur envoie une requête pour une certaine donnée IoT. Pour produire cette donnée, il est nécessaire de récupérer une ou plusieurs mesures brutes de capteurs et d’effectuer des calculs sur ces mesures brutes. Comme souvent dans les interactions hommes-machine, l’utilisateur attend une réponse dans une latence de l’ordre de 100 ms [34]. Deux solutions de calcul et de stockage sont disponibles : le Fog, qui fournit une capacité de calcul et de cache fixe mais sans frais, et le Cloud, qui fournit une capacité de calcul et de cache infinie mais avec un coût qui croit en fonction de leur utilisation. Afin de répartir les requêtes entre Fog et Cloud, une stratégie de contrôle d’admission est déployée devant le Fog. Pour chaque requête, la stratégie décide ou bien d’accepter la requête dans le Fog, ou bien de la rediriger vers le Cloud. La problématique à résoudre est donc la suivante : comment trouver une stratégie qui minimise les coûts de Cloud tout en gardant le temps de réponse moyen sous une limite donnée ?
Pour répondre à cette problématique, un modèle mathématique est proposé, fondée sur un réseau de file d’attentes. Chaque file du modèle est choisie à partir d’exemples pertinents dans la littérature. En particulier, le réseau est représenté par une file M/G/1-PS, représentant le partage du réseau entre les différents
flux [149,163,164]. Pour les plateformes de calcul, le Fog est représenté par une file M/G/1-PS, qui représente sa capacité finie [149,162], tandis que l’élasticité parfaite du Cloud est représentée par une file M/G/∞. Enfin, la stratégie de contrôle d’admission est représentée par une fonction φ : r → [0, 1] qui à une requête pour une donnée r associe une probabilité d’être accepté dans le Fog. Le modèle de file d’attente peut ainsi être utilisé pour calculer le temps de réponse moyen et le coût associé à chaque stratégie.
B.3.2
La stratégie LRU-AC
Il y a trois chemins possibles pour une requête dans le système Fog-Cloud : le Cloud, le cache du Fog, ou le système de calcul du Fog. Comme le système de calcul du Fog a une capacité fixe, l’unique solution pour augmenter la capacité globale de Fog est d’augmenter le taux de succès du cache. Pour ce faire, une stratégie de contrôle d’admission pour le Fog est de sélectionner uniquement les requêtes pour des données populaires, qui auront une probabilité plus élevée d’être dans le cache.
Pour faire cette sélection, il faut donc être capable de (i) identifier la donnée cible pour chaque requête et (ii) d’en extraire des prédictions de popularités. La solution présentée dans cette thèse, appelée le LRU-AC, remplit ces deux condi- tions, avec l’avantage supplémentaire d’avoir une implémentation performante en termes de débit et de latence car elle peut être réalisée sur du matériel de type FPGA [153].
Identification des données cibles
Pour identifier les données cibles, le LRU-AC repose sur une architecture ICN spécifique, appelée hICN (pour Hybride-ICN) [154]. hICN est une architecture ICN construite dans IPv6/TCP, c’est à dire que les champs des en-têtes IP et TCP sont utilisé pour fournir une sémantique ICN. En particulier, les données sont nommées en utilisant (pour un Intérêt) l’adresse IPv6 de destination sous la forme d’une location (préfixe de 64 bits) et d’un identifiant (suffixe de 64 bits). Cette architecture est particulièrement intéressante pour le cas d’usage du contrôle d’admission en FPGA, car elle permet d’accéder à une sémantique applicative dans l’en-tête réseau grâce à des champs qui ont une position et une taille constante. En particulier, cela permet de réutiliser tous les outils développés pour IP comme la plateforme P4 [155].
Prédiction de popularité
Pour prédire la popularité des requêtes, le LRU-AC utilise un filtre LRU, i.e., un méta-cache sur les identifiants des données avec la politique d’éviction dite de l’objet utilisé le moins récemment (LRU). En effet, la présence (resp. absence) d’un identifiant dans un tel cache indique qu’il s’agit probablement d’une donnée populaire à accepter dans le Fog (resp. impopulaire à rediriger dans le Cloud). En particulier, le comportement d’un tel cache peut être prédit en fonction de la distribution de popularité des requêtes grâce à l’approximation de Che [165], ce qui permet d’intégrer cette stratégie dans le modèle de file d’attente présenté plus haut.
B.4. ORCHESTRATION D’APPLICATIONS ET GESTION DE RÉSEAUX CENTRÉS CONTENUS129