Comparaison avec PEDAMACS

Dans cette section nous présentons les résultats de simulation de RTXP et PE-DAMACS avec les modèles de pertes en espace libre et log-normal shadowing. Nous comparons les délais de bout en bout, l’énergie consommée lors des simulations et le taux de livraison des deux protocoles.

Paramètres théoriques de PEDAMACS

A notre connaissance, RTXP est le premier protocole qui est à la fois, temps-réel,

cross-layer et localisé pour les RCsF. Les solutions cross-layers temps-réel existantes

sont centralisées. Nous nous comparons donc à ce type de solutions. Comme décrit dans la section 2.2.3 du Chapitre 2, dans le cas de PEDAMACS, le puits produit une trame d’ordonnancement globale basée sur une connaissance globale de la topologie du réseau (acquise au préalable lors d’une phase d’initialisation). Dans cette section, nous définissons le délai pire cas de PEDAMACS ainsi que la consommation d’énergie nécessaire pour qu’un paquet fasse un saut en direction du puits.

Dans [Coleri, 2002], les auteurs affirment que tous les paquets atteignent le puits durant au plus la durée d’une phase d’ordonnancement (c’est-à-dire avant la fin de la trame d’ordonnancement). La longueur maximale de la trame d’ordonnancement dépend de la topologie du réseau (représenté par un arbre enraciné au puits), plusieurs cas sont détaillés dans [Coleri, 2002]. Dans ce chapitre, nous considérons le cas d’un arbre G = (V, E) avec un modèle d’interférence à 2 sauts. Ce graphe est récupéré par le puits durant les phases d’initialisation (c.f. section 2.2.3). Dans ce cas, la durée maximale de la trame est :

W CT TP EDAM ACS = 3 × (|V | − 1) × Tslot (5.9) L’Equation 5.9 montre que, dans le cas de PEDAMACS, la borne sur le délai de bout en bout ne dépend pas directement du nombre de sauts entre la source et la destination mais du nombre de nœuds (le pire cas étant un réseau ligne, le nombre de nœuds |V | − 1 est alors égal au nombre de sauts).

Nous évaluons l’énergie consommée pour qu’un paquet effectue un saut en di-rection du puits. Pour PEDAMACS, cela correspond seulement à l’énergie nécessaire pour envoyer le paquet et pour le recevoir (on ne prend pas en compte l’initialisation).

E_{1hop_P EDAM ACS} = ET X_packet+ ERX_packet (5.10) Lors des simulations, nous comparons les délais observés avec les bornes théoriques de RTXP et PEDAMACS, exprimées respectivement par les Equations 5.6 et 5.9. Sur les graphes présentés dans cette section, nous avons choisi de représenter le délai de bout en bout de chaque paquet (croix sur les graphes) pour pouvoir observer la distribution des valeurs. Nous représentons également le délai moyen (courbe avec les cercles) et la borne théorique (trait épais).

Modèle de pertes en espace libre.

(a) 1 paquet toutes les 5 secondes (b) 1 paquet par seconde

Figure 5.5 – Délais de PEDAMACS (cas des pertes en espace libre)

Les Figures 5.5(a) et 5.5(b) représentent le délai de bout en bout des alarmes en fonction du nombre moyen de voisins dans le réseau pour PEDAMACS, respective-ment pour des trafics de 1 paquet toutes les 5 secondes et 1 paquet par seconde. Nous notons d’abord que tous les paquets respectent leurs échéances. Cela est assuré par l’ordonnancement global. De plus, l’ordonnancement assure aussi que deux nœuds interférants ne peuvent pas communiquer au même instant. Comme c’est la seule source de perte de paquets, nous observons un taux de livraison de 100%. Le délai n’est pas affecté par la charge de trafic car la trame d’ordonnancement ne change pas en fonction du trafic.

Les Figures 5.6(a) et 5.6(b) représentent le délais de bout en bout des alarmes et la borne théorique pour RTXP. Dans ce cas aussi nous observons que tous les paquets sont reçus avant l’échéance, comme prédit dans la section 5.6. Le taux de livraison est de 100%. Par contre dans le cas de RTXP, l’augmentation de la charge de trafic affecte le délai, cela produit une augmentation du délai de certains paquets. Cela est dû au fait que lorsque la charge augmente, cela déclenche plus de périodes d’activité secondaires car il y a plus de paquets au même instant dans un même 2-voisinage. En revanche, le délai ne varie pas en fonction du degré moyen du réseau.

(a) 1 paquet toutes les 5 secondes (b) 1 paquet par seconde

Figure 5.6 – Délais de RTXP (cas des pertes en espace libre)

Figure 5.7 – Consommation d’énergie maximale (sur 20 simulations par point) de PEDAMACS et RTXP

Consommation d’énergie. La Figure 5.7 représente la consommation d’énergie

maximale observée. Chaque point de la courbe est le maximum de 20 simulations sur des topologies comportant le même nombre de nœuds. Le calcul d’énergie pour RTXP et PEDAMACS se fait respectivement d’après les Equations 5.8 et 5.10.

L’énergie consommée par PEDAMACS n’augmente pratiquement pas quand le de-gré moyen du réseau augmente. L’énergie dépensée est fonction de l’ordonnancement et du trafic, car les nœuds se réveillent dans les slots qui leurs sont alloués pour rece-voir des paquets (même s’il n’y a pas de trafic) et envoient dans les slots d’émission (seulement s’ils ont des paquets). Le nombre de paquets émis étant toujours le même dans les simulations, l’augmentation de la charge n’augmente pas la consommation d’énergie.

L’énergie dépensée par RTXP augmente linéairement avec le degré moyen. Comme on l’a évoqué dans la section 5.6, c’est dû au fait que les paquets sont envoyés en

broadcast aux voisins de l’émetteur. L’augmentation de la charge de trafic provoque

une augmentation de la consommation d’énergie, c’est dû au déclenchement de plus de périodes d’activité secondaires.

PEDAMACS a une plus forte consommation d’énergie que RTXP pour des réseaux avec un degré moyen en dessous de 50. Cela est dû au fait qu’avec PEDAMACS les nœuds se réveillent, même s’il n’y a pas de trafic, à cause de l’ordonnancement. PE-DAMACS est donc plus adapté à un trafic périodique où tous les nœuds ont un paquet à envoyer dans chaque trame d’ordonnancement, plutôt qu’à des remontées d’alarmes (pour lesquelles le trafic est moins important et apériodique). RTXP au contraire s’adapte au trafic. S’il n’y a pas d’alarme, les nœuds dorment la plupart du temps, s’il y a beaucoup d’alarmes, des périodes d’activité secondaires sont déclenchées pour écouler le trafic.

Modèle de propagation Log-normal shadowing

(a) Délai (b) Taux de livraison

Figure 5.8 – Délais et taux de livraison de PEDAMACS (cas du modèle log-normal

shadowing)

La Figure 5.8(a) représente le délai de bout en bout et la borne théorique pour PEDAMACS dans le cas du modèle de propagation log-normal shadowing. Comme dans le cas du modèle de pertes en espace libre, on observe qu’aucun paquet n’arrive au puits après l’échéance. Cependant, la Figure 5.8(b) représente les taux de livraison minimum, maximum et moyen observés durant les simulations. Les valeurs sont faibles (entre 20 et 30 % de paquets reçus). La plupart des paquets sont perdus à cause des mauvaises conditions du canal radio. De plus, PEDAMACS n’implémente pas de mécanisme de retransmission de paquet, quand une transmission échoue, le paquet est définitivement perdu.

La figure 5.9(a) représente le délai de bout en bout et la borne théorique pour RTXP dans le cas du modèle de propagation log-normal shadowing sans

(a) Délai (b) Taux de livraison

Figure 5.9 – Délais et taux de livraison de RTXP (cas du modèle log-normal

shado-wing sans retransmission)

sion. Comme dans le cas de PEDAMACS, tous les paquets qui atteignent le puits respectent l’échéance. Mais dans ce cas, le taux de livraison des paquets (Figure 5.9(b)) est plus important. C’est grâce au routage opportuniste qui augmente la fia-bilité comme montré théoriquement dans le Chapitre 3.

(a) Délai (b) Taux de livraison

Figure 5.10 – Délais et taux de livraison de RTXP (cas du modèle log-normal

sha-dowing avec retransmissions)

La figure 5.9(a) représente le délai de bout en bout et la borne théorique pour RTXP dans le cas du modèle de propagation log-normal shadowing avec retransmis-sions. Dans ce cas, on remarque que quelques paquets ne respectent pas l’échéance. Le mécanisme de retransmission est décrit dans la section 5.5, si le nœud émetteur d’un paquet ne reçoit pas de jamming code durant la phase BF, il envoie un jamming

code dans le slot L et cela déclenche une nouvelle période d’activité durant laquelle

l’émetteur retransmet le paquet. Pour limiter la consommation d’énergie, un nœud peut tenter de transmettre un même paquet 5 fois par cycle d’endormissement (il pourra ensuite retenter dans le cycle suivant). Dans certains cas, le paquet peut être retardé de plusieurs cycles d’endormissement, il rate donc l’échéance. Cependant, le mécanisme de retransmission permet d’obtenir un meilleur taux de livraison même avec de mauvaises conditions du canal radio. La Figure 5.10(b) représente les taux de livraisons minimum, maximum et moyen observés durant les simulations (les délais restent inchangés et ne sont donc pas représentés ici). Les valeurs sont plus élevées que dans les cas de PEDAMACS et de RTXP sans retransmission.

Figure5.11 – Taux de livraison de RTXP (cas du modèle log-normal shadowing avec retransmissions et deux puits)

Dans le Chapitre 3 nous concluons que dans le cas d’un routage opportuniste, l’utilisation de plusieurs puits augmente la fiabilité. Nous observons donc l’impact de l’ajout d’un deuxième puits à côté du premier sur le taux de livraison de RTXP. La Figure 5.11 représente les taux de livraison minimum, maximum et moyen pour RTXP avec retransmissions et deux puits. On constate en effet une augmentation significative du taux de livraison, confirmant les résultats théoriques du Chapitre 3.

Avec des liens non-fiables, il est impossible de garantir qu’absolument tous les pa-quets sont reçus. Il n’est pas non plus possible de garantir qu’ils sont tous reçus avant l’échéance. Cela est dû à la nature probabiliste du lien radio. En effet, il existe une probabilité non nulle pour qu’un paquet ne soit pas reçu même après de nombreuses retransmissions. RTXP est conçu pour éviter les comportements probabilistes, l’accès au canal et la sélection du relayeur sont déterministes. Le comportement du protocole est prédictible et permet d’assurer que les paquets respectent leurs échéances. Cepen-dant, le lien radio introduit un comportement probabiliste, on peut donc légitimement se demander dans quelle mesure il est utile d’avoir un protocole déterministe avec un canal probabiliste. Cet aspect est exploré dans la section suivante.