Wifi low power : Différence entre versions

De Ensiwiki
Aller à : navigation, rechercher
 
Ligne 1 : Ligne 1 :
 
[[Catégorie:Projets]]
 
[[Catégorie:Projets]]
 
[[Catégorie:Projets Réseaux Mobiles et Avancés]]
 
[[Catégorie:Projets Réseaux Mobiles et Avancés]]
 +
 +
{{
 +
Projet Étudiant
 +
|titre = Wifi low power
 +
|cadre= Projets Réseaux Mobiles et Avancés
 +
|equipe= Valerian BAILLET, Matthias BEAUPÈRE
 +
|encadrants=[mailto:Franck.Rousseau@imag.fr Franck Rousseau]
 +
}}
  
 
== Introduction ==
 
== Introduction ==

Version actuelle en date du 9 avril 2018 à 11:04


Project schedule.png
Titre du projet Wifi low power
Cadre Projets Réseaux Mobiles et Avancés

Équipe Valerian BAILLET, Matthias BEAUPÈRE
Encadrants Franck Rousseau


Introduction

Dans le cadre de notre cours de réseaux mobiles, nous devions réaliser, par groupe, un projet sur une technologie réseau. Nous avons choisi de nous intéresser aux nouvelles normes Wifi ainsi qu'au Wifi low power.

Dans le monde actuel, les objets sont de plus en plus connectés grâce à internet (téléphone, enceintes, objet domotique...). Cependant cette connexion est très énergivore, il faut alors essayer de trouver des manières de réduire ce coût.

Dans la suite, nous nous intéresserons au fonctionnement du wifi avec les différents cas d'usages du wifi low power et nous finirons par décrire une expérience pour voir son fonctionnement.


Wifi : Normes

Dans cette partie nous allons parler de la norme IEEE 802.11, norme qui régie le wifi.

Normes IEEE 802.11

Les normes 802.11 sont un ensemble de norme concernant le réseau wifi. Celles-ci permettent une base de travail cohérente pour les constructeurs d'équipement réseaux wifi. Depuis 1997, de nombreuses amendements ont été ajoutés aux normes initiales. On note principalement deux types de normes: les normes sur la couche phy et normes sur la couche MAC.

Normes sur la couche physique

Les normes sur la couche physique servent à modifier le mode de transmission des données. Actuellement, deux normes sont utilisées dans le monde: la norme 802.11n (publiée en 2009) et la norme 802.ac (publiée en 2014). La différence se trouve dans la bande fréquence utilisée par les réseaux wifi. La norme 802.11n peut avoir une bande de fréquence de 2.4 GHz ou 5 GHz alors que l'autre norme ne marche que sur une fréquence de 5 GHz. Cependant la norme publiée en 2014 permet d'avoir un débit nettement supérieur, environ 433 Mbit/s contre 200 Mbit/s.

Normes sur la couche MAC

Les normes sur la couche MAC permettent de définir la sécurité d'accès ainsi que l'interfonctionnement entre les réseaux. Elles permettent, par exemple, de faire de la récupération dynamique des contraintes de transmissions (puissance max, canaux autorisés) ou encore l'augmentation de la sécurité des trames de management.


Modèle OSI avec les différentes normes 802.11


Nouvelle norme : 802.11ah

Une nouvelle norme vient juste d'être ratifiée (2016): la norme 802.11ah, appelée Halow. Cette norme a pour but de créer un wifi compatible avec l'internet des objets. C'est un protocole qui vise les nouveaux objets connectés tels que les montres, les bracelets ou les équipements de domotique.

Contrairement aux normes décrites précédemment, la norme Halow utilise une bande de fréquence beaucoup plus basse autour de 900 MHz. Cela permet de mieux conserver l'intégrité des signaux à travers des obstacles physique. Cela permet de diminuer le coût d'envoi et de réception des données. De plus, cette norme permet une augmentation de la portée du wifi.

La principale avancée, celle qui va nous intéresser principalement, est l'existence du mode veille. Un appareil connecté va pouvoir endormir sa carte réseau pour éviter de consommer de l'énergie quand elle n'est pas utilisée. Un signal venant des autres objets connectés permettront de réveiller sa carte lorsqu'il doit recevoir des données.

La contrepartie d'une bande de fréquence plus basse, du mode veille et de l'économie d'énergie lors de la transmission est un débit beaucoup plus faible, seulement 8 MBit/s.

Wifi actuel

Infrastructures possibles

Le wifi peut être utilisé de deux façons possibles:

  • Le mode Ad-Hoc  : ce mode évite d'utiliser un point d'accès pour gérer le réseau. Les trames reçues par une machine sont retransmises aux autres ordinateurs. Le problème est que la bande passante du réseau dépend de l'hôte qui a le plus faible débit et est divisée par le nombre du réseau. Ce mode peut être utilisé par un réseau local, dans une maison par exemple.
  • Le mode infrastructure : dans ce mode, tout est géré par un point d'accès. Les données sont émises au point d'accès qui se charge de les retransmettre aux autres hôtes du réseau. La bande passante est donc économisée. C'est ce mode qui nous intéresse principalement.

Avantages /Inconvénients

Déployer un réseau wifi offre de nombreux avantages :

  • Mobilité : les personnes peuvent se déplacer beaucoup plus librement.
  • Facilité : le wifi peut couvrir des endroits difficile d'accès par câble et peut relier différents immeubles entre eux.
  • Coût : un réseau wifi coûtent souvent moins cher en maintenance qu'un réseau par câbles filaires.
  • Évolutivité : un réseau wifi peut facilement évoluer au cours du temps, au gré des besoins des utilisateurs.

Cependant, il existe quand même quelques inconvénients:

  • Qualité du signal  : le signal peut se détériorer lorsqu'il traverse des objets physiques.
  • Sécurité  : la sécurité du réseau n'est pas forcément fiable (voir sécurité du wifi)

Utilisation de beacon frames

Le wifi actuel utilise des trames balises (beacon frames en anglais) pour donner son statut périodiquement aux différents hôtes alentours. Cette trame balise contient, entre autres:

  • le SSID (Service Set Identifier) : le nom du réseau wifi.
  • un Timestamp  : cela permet aux autres stations de changer leurs horloge, pour une meilleure synchronisation.
  • des informations de capacité : contient les capacités du réseau, comme sa configuration Ad-Hoc ou infrastructure.
description d'une trame balise


Ces trames sont envoyées par intervalles réguliers aux autres clients. Cette trame est très importante pour le fonctionnement de systèmes. Un hôte va pouvoir scanner les différentes trames balises qu'il reçoit et peut créer une liste de réseau wifi éligibles. Les trames balises permettent aussi d'annoncer des changements de configuration pour le réseau wifi appareillé.

L'intervalle de diffusion d'une trame balise est souvent fixé par défauts à 100 ms mais peut être paramétrer par l'administrateur du système. Il y a de nombreux avantages à modifier la durée de cette intervalle :

  • intervalle plus court  : cela permet de découvrir plus rapidement les différents routeurs d'un réseau wifi. Il donne une meilleure chance aux autres de capter les trames balises des réseaux wifi de faible intensité.
  • intervalle plus long  : un intervalle plus long permet de laisser de la bande réseau pour la transmission de données, ce qui augmente la bande passante et performance du réseau. Mais le plus intéressant est pour les hôtes qui possèdent une gestion du wifi. Si l'intervalle est suffisamment long, il permet aux hôtes d'endormir leur carte wifi. C'est ce qu'on appelle le wifi low power, apporté par la norme 802.11ah. Nous allons aborder son fonctionnement dans la section suivante.

Wifi low power

Fonctionnement

Le wifi low power va fonctionner grâce à deux actions: l'endormissement de la carte réseau du périphérique et l'ajout d'une d'information DTIM (Delivery Traffic Indication Message) dans ses trames balises.

Un hôte va pouvoir endormir sa carte réseau s'il ne reçoit pas de messages du point d'accès depuis un certain moment. Par défaut, l'endormissement se fait après 100ms. Les trames balises comptent comme des messages réseau donc il faut allonger l'intervalle d'envoi des trames balises pour permettre l'endormissement. À partir de ce moment, le point d'accès ne va pas transmettre des données tant que le périphérique est endormi. Il va les stocker dans un buffer jusqu'à ce qu'il puisse transmettre.
Le réveil de la carte réseau se passe par la réception d'une trame balise avec une information DTIM. Le DTIM permet de dire au périphérique que l'hôte va lui envoyer des données et qu'il doit réveiller sa carte wifi. L'information DTIM est envoyée après qu'un certain nombre de trames balise aient été envoyées. Par défaut, l'information DTIM est envoyée toutes les deux trames balise.

Capture des informations DTIM

Lorsqu'un administrateur réseau configure son réseau, il doit donc faire attention à la largeur de l'intervalle de transmission des trames balises ainsi que la période d'envoi des DTIM. Cela permettra la mise en veille des cartes réseaux des périphériques associés à son réseau. Il faut quand même noté qu'un endormissement prolongé d'un périphérique, entraînera forcément un durée d'éveil plus long car il faut pouvoir recevoir toutes les données stockés par le point d'accès.

Cas d'utilisation

On peut noter de nombreux cas d'utilisation du wifi low power. Par exemple, pour des objets connectés comme les montres ou les lunettes, il est possible d'économiser de la batterie car on ne transmet pas en continu. De plus, grâce à sa basse fréquence d'émission, on pourra utiliser plus facilement ses objets. Des ingénieurs ont pu crée un réseau wifi qui consomment 10000 moins d'énergie que le wifi actuel (voir ici). Cela peut permettre une baisse de la consommation énergétique, qui est un enjeu dans le monde actuel.

Performances

Plusieurs études ont essayer de montrer les performances du l'économie de batterie grâce à la mise en veille de la carte réseau. D'après cette étude, on peut voir que les gains en énergie ne sont pas très flagrant. Cela peut avoir plusieurs causes. Tout d'abord, le wifi n'est pas la principale source de dépense énergétique des mobiles. L'écran consomme beaucoup plus de batterie, donc une utilisation différente de l'écran (luminosité de l'endroit par exemple) peuvent entrainer facilement une hausse de la consommation énergétique. De plus, il se peut que la réception trop rapproché de trames réseau a empêcher le portable de mettre en veille sa carte wifi. Enfin, on peut noter la jeunesse de cette technologie, ce qui peut expliquer que le fonctionnement n'est pas encore optimisé.

Cas pratique

Dans cette partie, nous allons décrire une expérience qui montre le fonctionnement d'un power save mode pour une carte wifi et les effets sur la transmission des paquets. Comme vu précédemment, nous savons que 2 paramètres sont intéressants à étudier:

  • l'intervalle d'émission des beacons frames
  • l'intervalle d'ajout des DTIM

Nous allons donc modifier ces paramètres pour voir leurs effets en fonction de l'état d'un périphérique (power save actif ou non). Les paquets envoyés seront des paquets ICMP fait grâce à un ping réseau.

Le matériel nécessaire à l'expérience:

  • deux udoos quad
  • deux câbles éthernet
  • deux câbles de connexion au udoo

L'expérience va se dérouler de la manière suivante: nous allons configurer un udoo en mode Access Point (AP), qui est un routeur, et un udoo en power saving mode. À partir de ce moment, nous allons modifier les paramètres de l'udoo AP pour voir les variations que cela entraîne sur l'envoi de paquet.

Nous allons commencer par décrire comment configurer un udoo en mode AP et en power saving mode. Puis, on verra comment relier un udoo à un routeur et pour finir nous verrons les différents résultats obtenus.

Configuration des udoos

Connection d'un udoo en série

Connection d'un udoo à internet par un câble ethernet

Il faut commencer par configurer une connexion ethernet sur le pc connecté au udoo. Suivre les indications de ce lien

Ensuite il faut configurer la connexion du côté du udoo. Pour cela, il faut:

  • se connecter au udoo en port série.
  • Récupérer l'adresse IP du port ethernet du pc. Dans cette exemple, nous prendrons l'adresse IP 10.42.0.1 comme adresse du pc.
  • Choisir un adresse pour le udoo dans la même plage que l'adresse du pc. Nous prendrons l'adresse IP 10.42.0.68 avec un netmask 255.255.255.0.
  • Nous allons configurer le port éthernet du udoo par la commande : sudo ifconfig eth0 <ip udoo>_addr netmask <netmask> up
  • Nous allons dire qui est le DNS. Dans notre cas, le pc connecté fera office de DNS : sudo route add default gw <ip du pc> eth0
  • Nous allons rajouter ce serveur DNS directement dans le fichier de configuration pour le rendre permanent à chaque démarrage. Pour cela, il faut utiliser la commande suivante : echo "nameserver <ip du pc>" >> /etc/resolvconf/resolv.conf.d/tail
  • Rebooter le udoo : sudo reboot
  • Vérifier que la connexion est effectué avec : ping google.fr

À partir de ce moment, le udoo sera connecté à internet dès qu'il sera connecté au pc en ethernet. Il est donc nécessaire de faire ce tutoriel qu'une seule fois.

Création d'un Access Point

Pour cela, il faut que hostapd soit déjà installé, ainsi que le paquet udoo-softapd.

Pour créer un AP, il faut commencer par éditer son fichier de configuration. Pour cela, il faut créer un fichier dans le dossier /etc/hostapd que nous allons nommer hostapd.conf. Voici un exemple fonctionnel de fichier de configuration:

interface=wlan0           
driver=nl80211            
hw_mode=g                 
macaddr_acl=0             
auth_algs=1               
ignore_broadcast_ssid=0   
ieee80211n=1              
dtim_period=2
beacon_int=100
ssid=UDOO hotspot       
channel=1               
wpa=2                   
wpa_key_mgmt=WPA-PSK    
rsn_pairwise=CCMP       
wpa_passphrase=udooboard

I C'est la configuration par défaut d'un AP au nom Udoo hostpot et comme mdp udooboard. On peut noter que l'information DTIM est envoyé tous les deux trames balises soit toutes les 200 ms. Il faut noter que ce réseau n'est pas connecté à internet. Il permet seulement à un périphérique de se connecter sur un réseau local fournit par le AP.

Il faut maintenant lancer automatiquement ce réseau dès que le udoo AP démarre. Pour cela il faut éditer le fichier /etc/defaut/hostapd et modifié la ligne suivante:

DAEMON_CONF="/etc/hostapd/hostapd.conf"

Cela permet de dire au service hostapd ou trouver le le fichier de configuration du réseau wifi. Il suffit au final de relancer le serveur hostapd avec la commande suivante : sudo service hostapd restart

Il est possible que hostapd ne se lance pas car le wlan0 ne peut pas être configurer. Si l'erreur hostapd error nl80211 could not configure driver-mode apparaît , c'est qu'un autre logiciel wpa_suppicant tourne. Nous allons donc le désactive en suivant les étapes :

  • installer aircrack-ng : sudo apt-get install aircrack-ng
  • Vérifier que wpa_supplicant tourne : airmon-ng check
  • Si wpa_supplicant tourne : killall wpa_supplicant
  • Relancer hostapd

Nous avons donc un AP fonctionnel, nous allons donc connecter l'autre udoo pour pouvoir faire des tests.

Connexion à un AP

Pour se connecter à un réseau wifi, il faut créer un fichier de configuration pour un interface. Dans ce tutoriel, le nom de notre interface wifi sera wlan0 . Nous allons créer un fichier, nommé interfaces, dans le dossier /etc/network/interface.d. Le fichier sera de la forme :

# wi-fi interface wlp2s0
auto wlp2s0
iface wlp2s0 inet dhcp
    wpa-ssid <le ssid du réseau>
    wpa-psk <la clé psk>

Pour récupérer le wpa-psk, il faut utiliser l'outil wpa_passphrase. S'il n'est pas disponible, il faut installer le paquet wpasupplicant. Par exemple, avec le ssid Udoo hostpot et un mot de passe udooboard nous avons:

wpa_passphrase "Udoo hotspot"
# reading passphrase from stdin
udooboard
network={
	ssid="Udoo hotspot"
	#psk="udooboard"
	psk=8321b8145a9797e6bd5888e18bdbacad1adc0c7861e56a0a341e635b601c46d8
}

Il faut alors rebooter la machine pour que les changements soient pris en compte.

Passage en power saving mode

Pour faire passer un udoo en power saving mode, il faut utiliser la commande suivante: sudo iw dev <interface> set power_save on

On peut vérifier l'état de l'interface réseau : sudo iw dev wlan0 get power_save


Expérience

Pour cette expérience nous avons configurer un udoo en mode AP et lui avons connecté un autre udoo en wifi. Nous allons donc faire plusieurs expériences pour vérifier l'activation du power save mode. Pour cela, le udoo en mode AP va envoyer 20 requêtes ping au udoo associé. Nous allons regarder les temps de latence et les comparer.

Expérience 1

Pour la première expérience, qui sera notre base de référence, nous avons les paramètres suivants :

  • DTIM = 2 (paramètre par défaut)
  • beacon intervalle = 100 (paramètre par défaut)
  • power save mode = OFF
  • Ping intervalle = 1s

Nous lançons les requêtes et nous obtenons les résultats suivants:

64 bytes from 192.168.100.13: icmp_seq=1 ttl=64 time=0.813 ms
64 bytes from 192.168.100.13: icmp_seq=2 ttl=64 time=0.763 ms
64 bytes from 192.168.100.13: icmp_seq=3 ttl=64 time=0.770 ms
64 bytes from 192.168.100.13: icmp_seq=4 ttl=64 time=5.64 ms
64 bytes from 192.168.100.13: icmp_seq=5 ttl=64 time=1.45 ms
64 bytes from 192.168.100.13: icmp_seq=6 ttl=64 time=0.732 ms
64 bytes from 192.168.100.13: icmp_seq=7 ttl=64 time=0.723 ms
64 bytes from 192.168.100.13: icmp_seq=8 ttl=64 time=0.711 ms
64 bytes from 192.168.100.13: icmp_seq=9 ttl=64 time=0.692 ms
64 bytes from 192.168.100.13: icmp_seq=10 ttl=64 time=0.673 ms
...

Cela sera notre base de référence.

Expérience 2

Pour la seconde expérience, nous avons les paramètres suivants :

  • DTIM = 10
  • beacon intervalle = 100
  • power save mode = OFF
  • Ping intervalle = 1s


Nous lançons les requêtes et nous obtenons les résultats suivants:

64 bytes from 192.168.100.13: icmp_seq=1 ttl=64 time=0.775 ms
64 bytes from 192.168.100.13: icmp_seq=2 ttl=64 time=0.663 ms
64 bytes from 192.168.100.13: icmp_seq=3 ttl=64 time=0.770 ms
64 bytes from 192.168.100.13: icmp_seq=4 ttl=64 time=7.54 ms
64 bytes from 192.168.100.13: icmp_seq=5 ttl=64 time=0.852 ms
64 bytes from 192.168.100.13: icmp_seq=6 ttl=64 time=1.46 ms
64 bytes from 192.168.100.13: icmp_seq=7 ttl=64 time=0.707 ms
64 bytes from 192.168.100.13: icmp_seq=8 ttl=64 time=0.811 ms
64 bytes from 192.168.100.13: icmp_seq=9 ttl=64 time=0.872 ms
...

Les résultats ne sont pas différents, donc la modification du DTIM ne change rien si le périphérique associé n'est pas en power saving mode.

Expérience 3

Pour la troisième expérience, nous avons les paramètres suivants :

  • DTIM = 2
  • beacon intervalle = 1000
  • power save mode = OFF
  • Ping intervalle = 1s

Nous lançons les requêtes et nous obtenons les résultats suivants:

64 bytes from 192.168.100.13: icmp_seq=1 ttl=64 time=1.01 ms
64 bytes from 192.168.100.13: icmp_seq=2 ttl=64 time=0.847 ms
64 bytes from 192.168.100.13: icmp_seq=3 ttl=64 time=0.955 ms
64 bytes from 192.168.100.13: icmp_seq=4 ttl=64 time=0.865 ms
64 bytes from 192.168.100.13: icmp_seq=5 ttl=64 time=0.874 ms
64 bytes from 192.168.100.13: icmp_seq=6 ttl=64 time=1.10 ms
64 bytes from 192.168.100.13: icmp_seq=7 ttl=64 time=0.800 ms
64 bytes from 192.168.100.13: icmp_seq=8 ttl=64 time=0.705 ms
64 bytes from 192.168.100.13: icmp_seq=9 ttl=64 time=0.692 ms
64 bytes from 192.168.100.13: icmp_seq=10 ttl=64 time=0.796 ms
...

Les résultats ne sont pas différents, donc la modification de l'intervalle d'émission des trames balises ne change rien si le périphérique associé n'est pas en power saving mode.

Expérience 4

Pour la quatrième expérience, nous avons les paramètres suivants :

  • DTIM = 2
  • beacon intervalle = 100
  • power save mode = ON
  • Ping intervalle = 1s

Nous lançons les requêtes et nous obtenons les résultats suivants:

64 bytes from 192.168.100.13: icmp_seq=1 ttl=64 time=26.2 ms
64 bytes from 192.168.100.13: icmp_seq=2 ttl=64 time=48.5 ms
64 bytes from 192.168.100.13: icmp_seq=3 ttl=64 time=68.3 ms
64 bytes from 192.168.100.13: icmp_seq=4 ttl=64 time=90.7 ms
64 bytes from 192.168.100.13: icmp_seq=5 ttl=64 time=115 ms
64 bytes from 192.168.100.13: icmp_seq=6 ttl=64 time=35.0 ms
64 bytes from 192.168.100.13: icmp_seq=7 ttl=64 time=57.4 ms
64 bytes from 192.168.100.13: icmp_seq=8 ttl=64 time=78.1 ms
64 bytes from 192.168.100.13: icmp_seq=9 ttl=64 time=100 ms
64 bytes from 192.168.100.13: icmp_seq=10 ttl=64 time=23.4 ms
...

On peut voir que le temps à augmenter, mais les trames arrivent toujours une par une. Cela veut dire que le périphérique ne mets pas sa carte réseau en sommeil car il reçoit trop souvent des trames réseaux.

Expérience 5

Pour la cinquième expérience, nous avons les paramètres suivants :

  • DTIM = 10
  • beacon intervalle = 100
  • power save mode = ON
  • Ping intervalle = 1s

Nous lançons les requêtes et nous obtenons les résultats suivants:

64 bytes from 192.168.100.13: icmp_seq=1 ttl=64 time=48.5 ms
64 bytes from 192.168.100.13: icmp_seq=2 ttl=64 time=70.0 ms
64 bytes from 192.168.100.13: icmp_seq=3 ttl=64 time=92.9 ms
64 bytes from 192.168.100.13: icmp_seq=4 ttl=64 time=118 ms
64 bytes from 192.168.100.13: icmp_seq=5 ttl=64 time=37.3 ms
64 bytes from 192.168.100.13: icmp_seq=6 ttl=64 time=59.2 ms
64 bytes from 192.168.100.13: icmp_seq=7 ttl=64 time=80.7 ms
64 bytes from 192.168.100.13: icmp_seq=8 ttl=64 time=105 ms
64 bytes from 192.168.100.13: icmp_seq=9 ttl=64 time=27.2 ms
64 bytes from 192.168.100.13: icmp_seq=10 ttl=64 time=48.4 ms
64 bytes from 192.168.100.13: icmp_seq=11 ttl=64 time=171 ms
...

On peut voir que les trames arrivent par paquet de 4. De plus, les temps de réponse des quatres trames sont différents. Cela veut dire que le périphérique s'endort et que lorsqu'il se réveille, le routeur lui envoie 4 requêtes avant que le périphérique se rendorme. Donc le DTIM a une importance dans le wifi low power

Expérience 6

Pour la sixième expérience, nous avons les paramètres suivants :

  • DTIM = 2
  • beacon intervalle = 1000
  • power save mode = ON
  • Ping intervalle = 1s

Nous lançons les requêtes et nous obtenons les résultats suivants:

64 bytes from 192.168.100.13: icmp_seq=1 ttl=64 time=1561 ms
64 bytes from 192.168.100.13: icmp_seq=2 ttl=64 time=561 ms
64 bytes from 192.168.100.13: icmp_seq=3 ttl=64 time=1608 ms
64 bytes from 192.168.100.13: icmp_seq=4 ttl=64 time=608 ms
64 bytes from 192.168.100.13: icmp_seq=5 ttl=64 time=1657 ms
64 bytes from 192.168.100.13: icmp_seq=6 ttl=64 time=657 ms
64 bytes from 192.168.100.13: icmp_seq=7 ttl=64 time=1704 ms
64 bytes from 192.168.100.13: icmp_seq=8 ttl=64 time=704 ms
64 bytes from 192.168.100.13: icmp_seq=9 ttl=64 time=1753 ms
64 bytes from 192.168.100.13: icmp_seq=10 ttl=64 time=753 ms
64 bytes from 192.168.100.13: icmp_seq=11 ttl=64 time=1801 ms
...

Nous voyons que le temps de a pris un facteur 10 par rapport à l'expérience précédente. De plus, les trames arrivent aussi par groupe. Cela veut dire que l'intervalle des trames balises est importante dans le wifi low power.

Conclusion des expériences

On peut voir que les paramètres de DTIM et d'intervalles des trames balises sont très importantes dans le wifi low power. Ils vont déterminer la latence du réseau et la fréquence à laquelle le périphérique va se réveiller et s'endormir. De plus, on peut voir que pour les périphériques qui n'utilisent pas le power saving mode, ces critères importent peu.

Conclusion

Le wifi low power a fait son apparition très récemment car il permet d'apporter une réponse aux problèmes de consommation d'énergie pour les objets connectés. Il permet une meilleure qualité du signal à travers les obstacles physique ainsi que la capacité d'endormir les cartes wifi si un périphérique n'a pas reçu depuis un bout de temps des trames réseau. Le réveil se fait grâce au informations DTIM qui sont incluses dans certaines des trames balises du réseau wifi. Pour finir, il faut noter l'importance de la configuration de l'intervalle d'émission des trames balises ainsi que la fréquence des DTIM. Ces paramètres permettent de spécifier la fréquence d'endormissement et de réveil des périphériques.

Sources

https://fr.wikipedia.org/wiki/IEEE_802.11
https://www.elprocus.com/how-does-wifi-work/
http://www.commentcamarche.net/faq/3020-wifi-cours-d-introduction
https://routerguide.net/beacon-interval-best-optimal-setting-improve-wireless-speed/
https://en.wikipedia.org/wiki/Beacon_frame