• Aucun résultat trouvé

Chapitre IV. Analyse conjointe des performances PHY et MAC

IV.3. Étude du protocole d’accès au canal

IV.3.1. Mécanisme DCF (« Distributed Coordination Function »)

Le standard 802.11 [46] définit deux variantes de la méthode DCF. Une méthode implémente le mécanisme RTS / CTS (« Request To Send/ Clear To Send »), l’autre non.

Dans sa version standard illustrée sur la Figure IV-6 , un nœud émetteur désirant communiquer écoute le canal. Si le canal est détecté libre à un instant t, le nœud attend un temps fixe de durée DIFS (DCF « InterFrame Space) défini par la méthode physique de transmission. Une durée variable et aléatoire calculée par l’émetteur dans une plage donnée appelée fenêtre de contention 𝐶𝑊 (« Contention Window ») est ajoutée à l’intervalle DIFS. Cette temporisation aléatoire (appelée « backoff ») est déterminée par un nombre aléatoire de slots temporels (entre 0 et 𝐶𝑊 − 1), choisi par un algorithme (binary exponential backoff (BEB)) exécuté quand le canal est occupé ou après chaque transmission.

Lorsque le temps d’attente est écoulé, l’émetteur transmet ses données (Data) si le canal est toujours libre. Sinon, l’émetteur attendra une durée correspondant à la fin de la transmission en cours (libérant à nouveau le canal) plus le temps d’attente fixé par DIFS et 𝐶𝑊. Avec ce mécanisme, lorsque le canal est libre, c’est le nœud au retard le plus faible qui peut envoyer ses données. Il y a cependant un risque de collision si deux émetteurs ont le même backoff.

À la réception des données, le nœud récepteur attend une période de durée SIFS (« short inter-frame space ») avant l’envoi d’une trame de notification (« acknowledgment » ACK) pour informer l’émetteur qu’il a bien reçu les données.

Le canal est ensuite libéré et les autres nœuds du réseau désirant émettre peuvent débuter la décrémentation de la fenêtre 𝐶𝑊 après la durée DIFS.

Une limitation de la méthode DCF standard provient de l'obligation pour un nœud désirant émettre de sonder le canal pour savoir s’il est libre. En effet, il est toujours possible que deux nœuds envoient leurs échanges en même temps si les deux émetteurs ne se perçoivent pas l’un l’autre en raison d’une portée limitée par exemple. C’est la problématique des nœuds cachés conduisant alors à des collisions.

Figure IV-6 : Chronogramme du mécanisme DCF standard

Ces collisions peuvent être réduites en utilisant la version DCF avec réservation du canal grâce au mécanisme RTS/CTS [46]. La contrepartie est l’introduction d’un délai de communication supplémentaire. Le scénario DCF avec RTS/CTS est illustré sur la Figure IV-7.

Le nœud émetteur voulant transmettre utilise une trame de contrôle courte appelée RTS pour informer le nœud récepteur de son désir de communiquer. La trame RTS indique la source, la destination et la durée. Les autres nœuds présents dans la zone de couverture de l’émetteur reçoivent cette trame et initialisent un compteur appelé NAV (« network allocation vector »). Pendant la durée du NAV, ils savent qu'ils ne doivent pas émettre de données au risque de provoquer des collisions.

Si le canal est libre, le nœud récepteur répond par une trame de contrôle appelée CTS incluant les mêmes informations que RTS, après une période de durée SIFS. Les autres nœuds présents dans la zone de couverture du récepteur initialisent à leur tour une durée NAV.

Après réception du CTS, le nœud émetteur attend une durée SIFS et envoie sa trame de données. Une trame d'acquittement ACK est transmise à l’émetteur après une durée SIFS, si le récepteur a correctement reçu la trame Data.

Le mécanisme RTS/CTS n'élimine pas complètement le risque d'avoir des collisions. Cependant, comme les trames RTS/CTS sont de petite taille, la qualité des transmissions est améliorée même s’il y a collision.

Figure IV-7: Chronogramme du mécanisme DCF avec RTS/CTS

Lorsqu’une tentative de transmission se termine avec succès ou respectivement avec une collision,les temps de transmission 𝑇𝑠𝑢𝑐𝑐 et respectivement 𝑇𝑐𝑜𝑙sont donnés par [135]:

{𝑇𝑠𝑢𝑐𝑐 = 𝑅𝑇𝑆 + 𝐶𝑇𝑆 + 𝐷𝑎𝑡𝑎 + 𝐴𝐶𝐾 + 3𝑆𝐼𝐹𝑆 + 𝐷𝐼𝐹𝑆𝑇

𝑐𝑜𝑙 = 𝑇𝑐_𝑅𝑇𝑆+ 𝑇𝑐_𝐶𝑇𝑆 (4. 24)

𝑇𝑐_𝑅𝑇𝑆 et 𝑇𝑐_𝐶𝑇𝑆 sont les temps écoulés si la collision se produit durant la phase de transmission de la trame RTS respectivement CTS. Ces temps sont donnés par [135]:

{ 𝑇𝑐_𝑅𝑇𝑆= 𝑅𝑇𝑆 + 𝐷𝐼𝐹𝑆

𝑇𝑐_𝐶𝑇𝑆 = 𝑅𝑇𝑆 + 𝐶𝑇𝑆 + 𝑆𝐼𝐹𝑆 + 𝐷𝐼𝐹𝑆 (4. 25)

Le calcul des temps de transmission des trames prend en compte les en-têtes insérés au niveau de la couche PHY ainsi que le délai de propagation maximum du signal pour effectuer un aller-retour entre les stations les plus éloignées du réseau, spécifié par le standard (𝑎𝐴𝑖𝑟𝑃𝑟𝑜𝑝𝑎𝑔𝑎𝑡𝑖𝑜𝑛𝑇𝑖𝑚𝑒 = 1µ𝑠) [136].

Parmi les indicateurs de la performance d’un réseau, on s’intéresse à l’impact de la méthode d’accès sur le délai entre les signaux audio des casques des pilotes et le point d’accès au plafond du cockpit relié au système de gestion audio de l’avion. C’est un paramètre critique dans le projet pour la qualité audio en temps réel qui est fixé à une borne de 2,5 ms.

Parmi tous les paramètres impactant la latence, l’étude se focalise sur le temps de transmission des paquets de données qui sera d’autant plus grand que le débit est faible, pour une taille de paquet donnée.

De nombreux travaux dans la littérature ont établi des modèles analytiques du fonctionnement des réseaux sans fil 802.11 avec un accès aléatoire au canal [135] , [137]-[139].

Un travail de référence est celui proposé par G. Bianchi [137] qui s’appuie sur une approche par chaîne de Markov à deux dimensions. L’auteur a proposé une modélisation du processus de backoff pour prédire le comportement du mécanisme DCF. Ce modèle avait pour but d’estimer le débit et d’évaluer la performance du protocole. Différents auteurs ont utilisé ce travail de référence en introduisant des caractéristiques pour améliorer le modèle ou pour calculer d’autres métriques de performance [140]. Par exemple, [139] s’est intéressé au calcul du délai moyen dans DCF en se basant sur les résultats analytiques de [137]. Cependant, l’analyse supposait que tous les nœuds du réseau peuvent écouter le canal, donc le problème des nœuds cachés était négligé. Cette hypothèse ne peut être garantie dans un réseau OWC tel que dans le cockpit. C’est pour cette raison que nous nous inspirerons d’une autre extension des travaux de G.

Bianchi proposée par Salah A. Alabady et al [135] qui tient compte de la possibilité d’avoir des

nœuds cachés. Dans ces études, les auteurs valident notamment la modélisation analytique proposée en fonction du nombre de nœuds y compris pour un nombre faible, ce qui correspond au cas étudié constitué de quatre casques audio et du point d’accès.