• Aucun résultat trouvé

Adaptation à la charge de trac : métriques de QOS

1.2 Travaux sur l'adaptation en réseaux ad hoc

1.2.4 Adaptation à la charge de trac : métriques de QOS

nie par le réseau car en cas de trac important le délai de transmission dans le réseau et le taux de perte, seront plus importants. Elle est un paramètre important

de performances des protocoles de routage [37] et a été prise en compte dans plu-

sieurs travaux. Leur objectif est de sélectionner une route la moins chargée, et/ou de répartir le trac.

 Le premier exemple utilise une métrique de charge calculée à partir du nombre de paquets en attente sur un n÷ud, la métrique est calculée localement et transmise sur le réseau par la signalisation de routage.

 Le deuxième exemple calcule sa métrique à partir du nombre de routes passant dynamique par un n÷ud et ses voisins.

 Le troisième exemple utilise une métrique calculée selon un taux d'émission et un taux de réception qui reète le débit résiduel d'un n÷ud.

Dynamic Load-Aware Routing (DLAR)

DLAR [38] est une extension du protocole standard DSR qui équilibre la charge

sur le réseau en sélectionnant les routes sur le critère d'état de charge des n÷uds in- termédiaires. La charge d'un n÷ud est dénie comme le nombre de paquets contenus dans les tampons mémoire associés à une ligne, et la charge d'une route est dé- nie comme constituée des diérentes charges des n÷uds de la route. Comme DSR, DLAR est un protocole de routage réactif qui a deux mécanismes principaux : la

découverte de route et la maintenance de la route. La gure1.10 illustre l'opération

de protocole DLAR pour la sélection de route.

Fig. 1.10  Exemple d'opération du routage DLAR

Dans la procédure de découverte de route de DLAR, le n÷ud source, S, diuse un paquet de recherche de route RREQ (Route Request) à ses voisins. Quand un n÷ud intermédiaire reçoit le paquet RREQ, il attache sa propre information de charge, avant de le retransmettre. Contrairement à DSR, un n÷ud intermédiaire n'envoie pas de paquet de réponse RREP (Route Reply) s'il connaît une route vers

la destination ; seul le n÷ud de destination répond de façon à garantir la fraîcheur des informations de charge de la route. Le n÷ud destination D peut recevoir plusieurs paquets RREQ par diérentes routes durant un certain temps (le temps maximal est celui associé à la route la plus longue), il choisit la meilleure route comme étant celle qui est le moins chargée, et envoie un paquet RREP au n÷ud source via le chemin inverse. Dans la gure, la route S-A-B-C-D est choisie comme étant la moins chargée (= 19 dans la gure).

Dans la procédure de maintenance de route de DLAR, les n÷uds intermédiaires qui sont sur une route supportant une session de données active, ajoutent périodi- quement leur information de charge aux paquets de données. Si le chemin actif est considéré comme engorgé, la source recommence la procédure de découverte de route et trouve une route alternative. Quand un n÷ud intermédiaire détecte une rupture de lien, il envoie un paquet d'erreur au n÷ud source qui relance alors la procédure de découverte de route.

La dénition de charge adoptée par DLAR est classique, et semble bien adaptée à une exécution en environnement de travail réel (par opposition à simulé). Cependant, elle ne reète pas entièrement la véritable charge du réseau, puisque les paquets mémorisés peuvent avoir des tailles variables et que par ailleurs elle ne considère pas l'eet d'attente du à la compétition d'accès dans la couche de gestion de l'accès au support (MAC).

Load-Balanced ad hoc Routing (LBAR)

LBAR [39] est également un protocole réactif pour des applications sensibles au

délai qui cherche un chemin, peu chargé, pour que les paquets de données soient

transmis avec un faible délai. [39] dénit, la charge d'un n÷ud, comme le nombre

total de routes passant par le n÷ud et ses voisins. Plus précisément, en notant Pi le

nombre total de routes passant par le n÷ud i, la métrique de routage d'une route

r : Mr est dénie comme suit :

Mr = X iεr  Pi+ X jεN (i) Pj   (1.11)

Où N(i) est l'ensemble des voisins à un saut du n÷ud i. Chaque n÷ud utilise l'information de ses voisins, qu'il obtient par la lecture de sa table de routage et par signalisation périodique de type HELLO ; le protocole ne prend pas en compte la variation de la longueur des paquets ni les sources de délai provoquées par le mécanisme de compétition de la couche MAC. Cet aspect est traité dans les travaux suivants avec l'introduction de nouveaux paramètres pour le calcul de la charge. Free-Degree Adaptive Routing (FDAR)

FDAR [40] allie les deux objectifs : rechercher une route avec un délai faible, en

évitant les routes congestionnées, et conserver une charge moderée sur l'ensemble du réseau. Pour ce faire il utilise deux métriques, Free-Degree (FD) of Nodes et Free-Degree of Routes.

Le Free-Degree of Nodes du n÷ud, noté, φ(i) est :

φ(i)def= αi

(βi)2

(1.12)

Où αiindique le taux de transmission du n÷ud i et βiindique le taux de réception

de n÷ud i. Pour les auteurs, l'équation 1.12 exprime la disponibilité du n÷ud par

rapport à l'activité de communication, dans le sens où : 1) il reste de la place si le taux de réception est susamment faible par rapport au débit maximal et 2) pour un taux de réception xe, la place disponible devient plus grande en augmentant le taux de transmission. Chaque n÷ud met à jour périodiquement ses taux de transmission et réception pour chaque unités de temps T, selon la méthode exponentially weighted moving average (EWMA), de la manière suivante :

( αi L99 w × αi + (1 − w) × ∼ αi βi L99 w × βi+ (1 − w) × ∼ βi (1.13)

Où w est un poids avec 0 < w < 1, α∼i et

βi sont respectivement les valeurs

courantes de αi et βi. Dans ce schéma, ces taux sont mesurés en nombre d'octets

et non en nombre de paquets. Plus concrètement, la variableα∼ est calculée comme

suit (∼β est calculé de façon similaire) :

α = 1

T × (αdata+ h + αhead) (1.14)

Où αdatareprésente la quantité de données transmises pendant les unités de temps

passées T (en octets), αhead est le nombre de trames ayant été transmises durant T ,

y compris les trames erronées, et h est la taille de l'en-tête de trame. L'équation1.14

reète l'eet de compétition de la couche MAC en comptant le nombre de trames erronées.

Le Free-Degree of Route r (φ(r)) représente l'activité globale de la route, (une plus grande valeur de FD indique une plus grande liberté pour la communication), il est déni comme suit :

φ(r) =X iεr (φ(i) + ψ(i)) =X iεr  φ(i) + X jεN (i) φ(j)   (1.15)

Où N(i) est l'ensemble des voisins à un saut du n÷ud i, et i est un n÷ud de la route diérent de la source et de la destination.

En cas de congestion, la charge de trac d'un n÷ud dépend également de la charge de ses voisins, car ils doivent se partager la bande passante (par le protocole MAC). Ceci est pris en compte par la variable trac interference autour du n÷ud

i: ψ(r), dénie par :

ψ(r) = X

jεN (i)

φ(j) (1.16)

Les n÷uds peuvent obtenir les degrés de liberté de leurs voisins par échange de messages HELLO. Après avoir calculé la valeur de fonction φ pour chaque route

connectant la source et la destination, l'algorithme choisit celle avec un degré de liberté, FD, maximum ; en cas d'égalité sur plusieurs routes le choix se fait sur le critère nombre de sauts.

Réexions : à propos de signalisation et mesure

Les adaptations présentées sont de niveau 3 et utilisent des métriques calculées avec des paramètres de niveau 3 (route) pour une auto-adaptation, DLAR, LBAR, ou de niveau 2 (trames) pour une adaptation inter-couches, FDAR. Cette dernière permet de prendre en compte la spécicité du réseau ad hoc concernant l'accès sans l partagé. Pour les deux types d'adaptation une signalisation de niveau 3 (dans la mesure où elle concerne le routage) est employée pour obtenir les paramètres en vue voisinage et réseau. Le protocole par la source DSR est utilisé pour une vue réseau et le protocole HELLO est utilisé pour une vue voisinage. Le protocole HELLO qui émet périodiquement des paquets entre voisins est utilisé également pour détecter la qualité d'une liaison. Cependant en raison de la nature stochastique du canal il se peut que la mesure sur un paquet HELLO ne soit plus valable sur le paquet suivant.

1.2.5 Adaptation à la dynamique de la topologie : métriques