Gestion de trafic intra et inter-cellulaire dans les réseaux sans fil

Transcription

1 Gestion de trafic intra et inter-cellulaire dans les réseaux sans fil Gwendal LE GRAND - Jalel BEN-OTHMAN - Éric HORLAIT Université Pierre et Marie Curie, Laboratoire d'informatique de Paris 6 8 Rue du Capitaine Scott, PARIS tel : fax : Gwendal.Le-Grand@lip6.fr, jalel.ben-othman@rp.lip6.fr, Eric.Horlait@lip6.fr RÉSUMÉ Dans les environnements mobiles offrant des garanties de qualité de service, il est difficile d assurer une continuité de débit aux applications sachant que les ressources disponibles ne sont pas uniformes sur la route que suit un mobile. Dans cet article, nous proposons un nouveau protocole (MIR : Mobile IP Reservation Protocol) qui fournit un tel service à des terminaux mobbiles. Ce protocole est une adaptation de CLEP (Control Load Ethernet Protocol) décrit dans [Horl 97] qui supporte la mobilité. L un des avantages de cette approche est l utilisation d un algorithme distribué n imposant pas de structure hiérarchique du réseau et permettant de gérer chaque cellule séparément en fonction de ses besoins. De plus, il n impose aucune connaissance a priori ni de la mobilté des terminaux ni de l architecture du réseau sans fil. Mots clés : Réseaux sans fil, mobilité, Qualité de Service, IEEE , NS, WaveLAN, Gestion de la bande passante, RSVP, Internet Protocol, Réseaux Locaux Introduction L apparition des équipements sans fil pose de nouveaux problèmes dans le monde des réseaux. En effet, les protocoles de l Internet ont été conçus pour les environnements filaires et s adaptent très mal aux environnements sans fil. Cela vient d une part de la qualité de l environnement de propagation qui est plus mauvais que celui que nous trouvons dans les réseaux filaires, et d autre part de la mobilité de l utilisateur. L objectif de notre recherche est de proposer des mécanismes permettant d améliorer la qualité de service offerte aux utilisateurs dans ce type d environnement en terme de débit, de probabilité de pertes et de probabilité de coupure d une connexion en cours de déplacement. Les environnements sans fil imposent des contraintes propres telles que l atténuation, l'allocation de fréquences, les interférences, la fiabilité, la sécurité, le débit et la mobilité. Dans cette étude, nous nous intéressons particulièrement à ce dernier point. La mobilité va engendrer des mécanismes supplémentaires de réservation de ressources dans toutes les cellules traversées par le mobile ; il est donc nécessaire d adapter les protocoles et les terminaux afin de rester connecté au réseau pendant des déplacements. En particulier, les systèmes sans fil doivent gérer le handoff, c'est à dire le basculement d'une communication d'une cellule à une autre.le protocole Control Load Ethernet Protocol (CLEP) [Horl 97] traite le problème de la gestion de la bande passante et des réservations pour fournir aux utilisateurs d un réseau partagé (par exemple un réseau Ethernet) une garantie de bande passante. Dans cette étude, nous avons étendu CLEP aux environnements sans fil pour offrir une qualité de service constante indépendamment de la mobilité de l utilisateur. MIR réserve des ressources dans les cellules où le mobile est susceptible de se rendre. La suite de ce document est organisée de la façon suivante : dans la deuxième partie, nous étudions les faiblesses du protocole Ethernet en terme de qualité de service et présentons une solution possible : CLEP. Dans la troisième partie, nous analysons le fonctionnement de CLEP et les résultats obtenus en environnement filaire. Dans la quatrième partie, nous décrivons MIR, une extension de CLEP adaptée à un environnement IP mobile. Nous proposons une amélioration de MIR dans la cinquième partie. MIR est évalué dans la sixième partie. Finalement, nous concluons par faire un résumé de notre contribution et par les travaux futurs. 2. Qualité de service dans les réseaux filaires 2.1. Limites du protocole Ethernet Ethernet ne fournit aucune garantie de qualité de service. La figure 1 met en évidence ce problème. Cette figure est obtenue par simulation sous NS [NS] et représente le débit obtenu par 20 sources UDP sur un même réseau Ethernet en fonction du temps. Lorsque la charge du réseau augmente, la bande passante totale utile est sous-

2 utilisée et chaque source dispose d un débit quasiment nul. De plus, un flux particulier ne peut pas avoir de garantie de débit puisqu Ethernet assure l équité entre les flux. Figure 1. Débit par source dans un réseau Ethernet filaire classique Figure 2. Token buckets dans chaque élément de réseau Plusieurs solutions ont été proposées pour pallier ces inconvénients. Yavatkar, Hoffman et Bernet [Yava 99] proposent une architecture centralisée pour gérer la bande passante dans les sous-réseaux. Cependant, un manager dédié doit être présent sur chaque LAN et le protocole repose fortement sur RSVP [Brad 97], qui doit être utilisé dans tout le réseau et pour tous les flux. De plus, cette approche ne traite pas les flux best-effort. Control Load Ethernet Protocol (CLEP) est une implémentation du service d équilibrage de bande passante proposé par Wroclawski dans [Wroc 97]. Pour chaque flux de données, on approxime la qualité de service de chaque flux par celle que ce flux obtiendrait sur un réseau peu chargé Principe de CLEP CLEP [Horl 97] permet de garantir une certaine qualité de service pour des trafics privilégiés et d optimiser l utilisation de la bande passante disponible. Pour cela, on attribue une spécification à chaque type de trafic en utilisant un token bucket (cf. figure 2), qui contrôle la charge sur les interfaces sortantes des éléments de réseau. Un token bucket est une forme particulière de Traffic Specification (Tspec), qui est un descripteur de trafic pour lequel un contrôle de QoS est requis. Un Tspec est constitué d un débit r et d une profondeur b. Les éléments du réseau utilisent un algorithme distribué pour gérer les paramètres des token buckets et utiliser le lien efficacement. On distingue deux types de flux : best effort et privilégiés. Le service de contrôle de charge gère l admission des flux : un flux n est admis sur le réseau que si la bande passante disponible le permet. La gestion des réservations est effectuée de manière distribuée sur chaque équipement du réseau. Un élément contient autant de filtres token bucket que de types de flots (best effort et privilégiés). Des files d attente précèdent les filtres afin de permettre la remise en forme du trafic sans perte de données. En effet, il est parfois nécessaire de remodeler le trafic pour tenter de le rendre conforme à la spécification de trafic. Lorsque cela n est pas possible, le flux concerné est traité comme du trafic best effort. Il existe deux files distinctes pour le trafic best effort selon qu il est prioritaire ou non ; CLEP permet donc de donner une plus grande priorité aux trafics à fortes contraintes de temps et de fiabilité. Tout élément de réseau calcule un débit pour le best effort et pour les flux privilégiés. Ces paramètres évoluent à chaque fois qu un nouvel élément apparaît sur le réseau ou qu une nouvelle réservation est nécessaire. Chaque équipement doit connaître le niveau de réservation du lien, afin de décider d accepter ou non de nouvelles réservations. Les paramètres de débit des token bucket sont émis périodiquement par les éléments du réseau. Ces messages contiennent quatre valeurs : - Rbe (le taux de trafic best effort), - Rmin (la valeur minimale de Rbe), - Rpriv (le débit du flux privilégié), - Rmax (le débit maximal sur le lien).

3 A chaque fois qu un paramètre varie, la bande passante disponible Rfree est recalculée. Lorsqu un nouvel élément arrive sur le réseau, ou que l on demande une nouvelle réservation, le débit best effort de chaque élément de réseau est diminué (tant que cette valeur est supérieure à un seuil r min ) jusqu à ce que le débit libre r free redevienne positif. Si r free reste négatif, la nouvelle réservation est rejetée. On calcule donc les paramètres de la manière suivante : rfree = r max ( r N Puis on calcule r free_be : r free_be + r ) be priv = r free si où N est le nombre d éléments de réseau et r max, le débit maximum sur le lien. < rbe rbe N = r free r max /100 sinon Lorsque la table des paramètres évolue, r free et r free_be sont mis à jour immédiatement. Si r free_be est négatif, l élément de réseau doit diminuer son r be de : r ( r r be r be min min *( ) r free_ be + 0.5), s il n a pas déjà atteint une valeur minimale. Pour la réservation d un flux privilégié (qui équivaut à augmenter r priv de z), l algorithme d admission suivant est utilisé : - Si z r free, la réservation est acceptée, - Si z > Σ (r priv + r min ), la réservation est rejetée, - Sinon, on diffuse un message dans le réseau, en remplaçant r priv par r priv + z. Le nouveau r free calculé par les éléments de réseau est négatif, et chacun des éléments diminue son r be pour rendre son r priv positif. Si après un certain temps, r free est toujours négatif, alors la réservation est rejetée. CLEP a été implémenté et simulé. Les résultats montrent une nette amélioration de la qualité de service des applications [Horl97] dont les débits restent constants. De plus, peu de paquets sont perdus même lorsque la charge du réseau varie. Nous allons maintenant présenter comment CLEP peut être étendu pour offrir des garanties de qualité de service dans les réseaux mobiles. 3. QoS en environnement sans fil Nous cherchons à fournir de la qualité de service dans un environnement mobile utilisant les protocoles Mobile IP et IEEE [IEEE 802] respectivement comme protocoles de niveau réseau et de niveau liaison. Mobile IP est sans doute le protocole le plus populaire pour supporter la mobilité des utilisateurs dans l Internet. Il supporte la mobilité de terminaux ne changeant pas d adresse IP. Mobile IP utilise en réalité deux adresses IP : la première pour identifier le mobile lui même et la seconde pour gérer le routage. Lorsqu un nœud mobile se déplace et se connecte sur un nouveau sous-réseau, il enregistre sa nouvelle care of address auprès de son home agent. Cette care of address est en fait l adresse d un foreign agent auquel le nœud est connecté. IEEE spécifie une couche MAC et une couche physique pour des connexions sans fil entre des stations fixes, portables ou mobiles à l'intérieur d'une zone géographique. Les communications cellulaires sur un canal de communication à quelques Mbit/s sont également définies. En environnement sans fil conforme à la norme IEEE avec RTS/CTS, les besoins en terme de qualité de service deviennent légèrement différents. En effet, l utilisation même de RTS/CTS signifie que la bande passante est réservée pour écouler un certain trafic, ce qui résulte en une bonne utilisation globale de la bande passante. Par contre, il est impossible de différencier les flux en terme de qualité de service puisque l équité est garantie grâce à CSMA/CA. Nous décrirons dans la suite comment nous résolvons ce problème. D autres travaux pour fournir de la QoS à des terminaux mobiles ont déjà été effectués. Par exemple, [Talu 98] propose MRSVP qui est une modification de RSVP [Brad 97] pour diminuer les probabilités de blocage. Cependant, cette technique nécessite des classes de service supplémentaires, des changements majeurs au niveau de RSVP, une connaissance a priori des déplacements du mobile (profil de mobilité) et une signalisation importante. Ce travail suppose que la mobilité d un utilisateur est prédictible de telle façon qu une spécification de mobilité peut être définie. Cette spécification représente la liste des localisations géographiques que le mobile va visiter pendant la durée de vie d un flux. Trois classes de service sont définies : MIG (Mobility Independent

4 Guaranteed Service), MIP (Mobility Independent Predictive Service), et MDP (Mobility Dependent Predicitve Service). Tant que les mobiles respectent le profil de mobilité, les utilisateurs ayant souscrit aux classes de service indépendantes de la mobilité ne sont pas affectées par la mobilité des utilisateurs. Les autres classes peuvent avoir des changements dans leurs paramètres de QoS lorsqu un handoff se produit. Cependant, afin de fournir des bonnes garanties à ces classes, des ressources sont utilisées tout au long des chemins possibles définis par le profil de mobilité. Nous pensons que prédire à l avance tous les déplacements d un mobile est difficilement réalisable. D autre part, ces réservations entraînent un gaspillage bien trop important des ressources du réseau. [Awdu 97] améliore RSVP de manière à l adapter aux environnements mobiles. Cette approche est similaire à celle de [Talu 98] : de nouvelles classes de service sont définies. Cependant, cette approche utilise des agents de gestion de la mobilité pour maintenir des profils de mobilité et envoyer des messages pour mettre en place les réservations. 4. MIR (Mobile IP Reservation Protocol) 4.1. Principes MIR est l extension de CLEP aux environnements mobiles. Il est conçu pour fournir des garanties de QoS à des utilisateurs mobiles, sans connaissance a priori de l architecture du réseau ou de la mobilité des terminaux. MIR est distribué, donc chaque cellule peut être gérée séparément en fonction du degré de mobilité des terminaux qui s y trouvent. Une cellule peut donc s adapter dynamiquement aux besoins en mobilité des terminaux et répartir sa bande passante selon ces besoins. Dans un environnement mobile, l objectif est de dimensionner le nombre de jetons alloués à chaque file en fonction du trafic considéré et de la mobilité des utilisateurs. L objectif de l adaptation de CLEP dans un environnement mobile est de prendre en compte de l aspect mobilité ; il s agit de savoir comment tenir compte de la réservation des ressources lors de l exécution d un handoff ainsi que d adapter les token buckets en fonction de ce nouvel événement. On impose seulement aux parties sans fil d utiliser MIR (figures 4 et 5) ; ces dernières peuvent donc obtenir des garanties de qualité de service. Cette hypothèse nous semble raisonnable puisque le reste du réseau, s il est filaire, offre probablement des débits supérieurs aux cellules sans fil. La partie filaire n est en général pas le goulot d étranglement. Sans mobilité des terminaux, le problème revient simplement à faire des réservations sur plusieurs réseaux locaux. Par contre, lorsque l un des terminaux se déplace et change de cellule, les réservations (routage et paramètres MIR) doivent évoluer. HA HA Réservation CLEP 2 Réservation CLEP HA : Home Agent FA : Foreign Agent MN : Mobile Node 2 HA : Home Agent FA : Foreign Agent MN : Mobile Node FA1 9 4 MN 2 6 FA2 1 FA1 6 4 MN 2 5 FA2 9 MN 1 5 MN 1 MN 1 MN 2 Cellule 1 avec MIR Cellule 2 avec MIR Cellule 1 avec MIR Cellule 2 avec MIR Figure 3. Réservations lors d un handoff d une station émettrice Figure 4. Réservations lors d un handoff d une station réceptrice On distingue deux cas selon que le terminal en déplacement est émetteur ou récepteur.

5 1. Déplacement de la station émettrice (figure 3) : Après le handoff, la réservation faite par MN1 dans la cellule 1 n a plus lieu d être. En revanche, il faut, si cela est possible, réserver des ressources dans la cellule 2 pour MN1. Puisque MN2 ne bouge pas, la réservation du Foreign Agent dans la cellule 1 doit toujours exister. 2. Déplacement de la station réceptrice (figure 4) : Après le handoff de MN2, MN1 doit conserver sa réservation dans la cellule 1. La réservation du Foreign Agent dans la cellule 1 est inutile et doit être remplacée par une réservation de FA2 dans la cellule 2. Dans les deux cas, on se ramène donc à un problème de routage et de déplacement des garanties de QoS. Lors de l exécution d un handoff, il faut mettre à jour les réservations le long de la nouvelle route entre MN1 et MN2. Lorsqu un mobile se déplace vers une nouvelle cellule, il doit conserver le même débit pour ses flux privilégiés ; Le trafic best effort quant à lui peut varier. Le mobile doit donc faire une réservation passive qui ne deviendra active que lorsque le handoff sera effectué (figure 5). Entre temps, les paramètres de MIR sont renégociés. FA1 Début de la négociation des nouveaux paramètres de QoS dans la cellule 2 FA2 Handoff : on utilise les parmètres de qualité de service de la cellule 2 Déplacement du mobile Seuil S1 Bande Passante Rmax_handoff uniquement pour les flux privilégiés Rmax_classic Seuil S2 Réservations passives (avec sur-réservation du médium) Réservations actives Flux privilégiés et flux best-effort (nouvelles connexions) Cellule 1 Cellule 2 Figure 5. Négociation des paramètres de qualité de service lors des déplacements Rmin_total Figure 6. Répartition de la bande passante totale dans une cellule Lors d un handoff. dans le meilleur des cas, la bande passante disponible dans C2 est suffisante et R priv2 vaut R priv1. Cependant, les cellules ayant probablement des caractéristiques différentes (en particulier R max et la charge), R be2, recalculé en fonction de la bande passante résiduelle dans C2, est différent de R be1. Un problème se pose si C2 ne dispose pas de la bande passante suffisante pour garantir le même Rpriv1. Nous décrivons dans 4.2 comment en réservant une partie de la bande passante de la cellule pour écouler ce flux privilégié lors du handoff on peut résoudre le problème Répartition des ressources entre les différents utilisateurs Pour la gestion des token buckets, nous proposons de séparer la bande passante de chaque cellule en deux parties. L une (R max_handoff ) est consacrée à l acheminement des flux privilégiés lors du handoff, tandis que l autre (R max_classic ) traite le trafic classique. R max représente la proportion de bande passante totale dans une cellule. De plus, nous allons effectuer des réservations passives pour les flux présents dans d autres cellules et qui effectueront peut-être un handoff. Une réservation passive correspond à une réservation de ressources sans utilisation réelle. Elle ne devient active que lorsque le mobile exécute son handoff. Ainsi, nous ne sommes pas limités par la bande passante réelle de la cellule. Il est donc possible de réserver plus de ressources que ce qui est réellement disponible dans la cellule. La surréservation correspond au seuil S2 de la figure Politique d allocation des ressources Pour les nouvelles connexions Soit S1 un seuil de tolérance des nouvelles connexions, représentant un pourcentage de la bande passante totale. Si la charge totale de la cellule reste inférieure à S1, les nouvelles connexions sont acceptées, sinon on diminue le débit des flux best effort jusqu au minimum r min de manière à allouer ces ressources aux nouvelles

6 connexions. Lorsque les sources best effort ont atteint leur débit minimum assuré, toutes les nouvelles connexions sont refusées Pour les handoffs Lorsqu un mobile se déplace et qu il reçoit un advertisement d un nouveau Foreign Agent, il commence a faire une réservation passive pour ses flux privilégiés dans les cellules voisines. Cela va donc faire diminuer le nombre de jetons alloués aux files best effort de tous les mobiles dans les cellules voisines. La réservation ne devient active que si le mobile exécute le handoff sur cette cellule. Les réservations pour les handoff des flux privilégiés pourront s effectuer jusqu'à un seuil S2. Après l exécution d un handoff, les ressources réservées et non utilisées sont libérées, soit par expiration d une temporisation, soit par désenregistrement du mobile auprès de son ancien Foreign Agent. Ceci permet d augmenter de nouveau le débit best effort. Après exécution d un handoff pour du trafic best effort, les jetons attribués à ces files sont supprimés le temps que le mobile renégocie de nouveaux jetons pour ces files. La négociation s effectue comme s il s agissait d une nouvelle connexion Calcul du nombre de jetons Le calcul du nombre de jetons revient à évaluer le débit alloué à chaque mobile. On a donc : S2= (1+Y).R max = (1+Y).(R max_handoff + R max_classic ) où Y correspond à la proportion de bande passante supplémentaire allouée grâce aux réservations passives. De plus, R max est constant dans une cellule mais R max_handoff et R max_classic peuvent varier en fonction des besoins en mobilité des utilisateurs. Le Foreign Agent évalue cette mobilité en comptant le nombre de nouveaux arrivés (B) dans la cellule pendant un intervalle de temps T donné. Puis, on calcule R max_classic = max (R max * (1-B/100), R min_total ) et donc R max_handoff = min(r max * B/100, R max - R min_total ), c est à dire que dans tous les cas, il y aura au moins R min_total pour le trafic best effort, même lorsque la mobilité des utilisateurs est très grande. Le Foreign Agent impose alors à toutes les machines de sa cellule les valeurs qu il vient de calculer en les diffusant dans un nouveau message MIR. Ainsi, chaque mobile peut mettre à jour son propre seuil S1. Nous allons maintenant présenter une amélioration possible de MIR. 5. Amélioration de MIR Afin d améliorer la QoS offerte, nous distinguons deux paramètres supplémentaires : la vitesse des terminaux (rapide ou lente) et le type de connexion (dégradable ou non). Nous différencions des types de flots privilégiés : dégradable et non dégradable. Par exemple, un flux audio sera toujours compris par l oreille humaine si une partie aléatoire de l information est supprimée. Un tel flux est un flux dégradable. De la même façon, certains flux deviennent incompréhensibles si l on retire une toute petite partie de l information. Ce sont les flux non dégradables. Dans certains cas, il peut être intéressant de dégrader certains flux pour pouvoir en admettre d autres. Un flux doit donc être caractérisé par un profil de perte. On peut alors dégrader l information à la source suivant ce profil et diminuer d autant le nombre de jetons associés à ce flux. Nous définissons quatre types de flux privilégiés suivant que le mobile se déplace rapidement ou lentement et suivant que la connexion est dégradable ou non. Puis nous appliquons une politique différente pour chaque type de flux. Si un mobile est lent et si le handoff ne peut être satisfait, la connexion doit être perdue. Cependant, si le mobile est rapide, la connexion doit simplement se suspendre le temps que le mobile reste dans la cellule ne pouvant offrir la QoS demandée. Nous définissons la politique décrite figure 7 : nous ajoutons deux seuils au modèle précédent. Trois états possibles. Dans le premier, toutes les connexions sont acceptées. Dans le second, tous les handoffs sont acceptés. Finalement, dans le dernier, seuls les handoffs rapides non dégradables sont acceptés. Nous choisissons de privilégier les connexions rapides pour deux raisons :

7 une connexion lente utilise la bande passante pendant longtemps, une réservation passive lente risque de ne pas devenir active avant longtemps. Lorsque la charge augmente, voici comment le réseau doit se comporter : lorsque la charge atteint S1, le trafic best effort diminue pour pouvoir accepter de nouvelles connexions. Lorsque tous les flux best effort ont atteint r min, on passe dans le deuxième état. Les flux dégradables rapides sont dégradés. Si la charge devient inférieure à S3, tout est à nouveau accepté. Sinon, les nouvelles connexions rapides sont acceptées. Si la charge est supérieure à S1, seuls les handoffs sont acceptés. A S2, les flux lents dégradables sont dégradés. Lorsqu il n y a plus de flux à dégrader, on atteint le troisième état. On refuse alors les handoffs lents non dégradables. Lorsque la charge retombe en dessous de S4, on revient dans le deuxième état. 6. Modélisation de MIR 6.1. Description du modèle Dans cette partie, nous décrivons comment nous avons modélisé la version simple de MIR qui a été décrite dans la partie 3. Afin de construire ce modèle, nous avons fait quelques hypothèses simplificatrices : - une connexion correspond à un jeton si bien que toutes les connexions utilisent la même bande passante. Si une nouvelle connexion arrive, soit elle peut être satisfaite et un jeton lui est attribué, soit elle n est pas satisfaite et aucun jeton n est distribué. La demande de connexion est alors bloquée. - r min n a pas été modélisé : si une nouvelle connexion privilégiée arrive, elle peut pré-empter n importe quelle connexion best-effort. Dans le protocole réel, une connexion best effort ne peut pas avoir un débit inférieur à r min. Nous faisons des observations sur une seule cellule et l on modélise tous les événements qui peuvent arriver : une nouvelle connexion (privilégiée ou best effort), un handoff passif ou un handoff actif. Les états définis dans le modèle ont trois dimensions : la première (i) est le nombre de jetons best effort, la deuxième (j) est le nombre de jetons pour du trafic privilégié et la troisième (k) est le nombre de réservations passives. Etat Handoffs et nouvelles connexions rapides privilégiées Dégrader les flux rapides dégradables Seulement les flux rapides non dégradables Bloquer les lents non dégradables Accepter tout Handoffs seulement S3 S1 S4 S2 Figure 7. Amélioration avec 4 seuils Dégrader les flux dégradables lents Bande Passante 6.2. Équations de transition Les équations qui suivent décrivent les transitions de la chaîne de Markov. Soient i, j et k les nombres de jetons best effort, privilégiés et passifs. Soient S1, S2 et Bw les nombres de jetons correspondant respectivement à une charge de S1, S2 et B. Soient λ i et µ i (pour i entre 1 et 5) les taux d arrivée et de départ d une nouvelle connexion privilégiée, d un handoff passif, d une connexion best effort, d un handoff best effort et d un handoff actif. Nous supposons que tous ces processus sont Poissoniens. Finalement, soit P(i,j,k,l,m,n) la probabilité de transition de l état (i,j,k) à l état (l,m,n). Dans les équations qui suivent, 1 ß(i,j,k) vaut 1 lorsque la fonction booléene ß(i,j,k) est vraie et 0 sinon. Nous utilisons une convention de type langage C : (i & j=s2-i) signifie (i>0 & j=s2-i). Les transitions partant de l état (i,j,k) sont : Vers l état (i,j,k) : 1 (i+j+k <S2) && (i+j >=S1) ( λ 3 +λ 4 ) +1 (i+j+k >=S2) && (i+j >=S1)( λ 3 +λ 4 ) +1 (i+j >s1) &&(i+j+k <S2) (λ 1 ) +1 (i+j =s1) && (i=0) &&(i+j+k <S2)(λ 1 ) +1 (i+j+k =s2) (λ 1 ) +1 (i+j+k =s2) && (i=0) (λ 2 )

8 +1 (i+j <Bw) && (k=0) && (i=0) (λ 5 ) +1 (i+j >=Bw) && (k=0) && (i=0) (λ 5 ) Vers l état (i+1,j,k) : 1 (i+j+k <S2) && (i+j >=S1)(λ 3 +λ 4 ) Vers l état (i-1,j+1,k) : 1 (i+j =s1) && (i) &&(i+j+k <S2) (λ 1 ) Vers l état (i,j+1,k) : 1 (i+j+k!=s2) (λ 1 ) Vers l état (i,j,k+1) : 1 (i+j+k <s2) (λ 2 ) Vers l état (i-1,j,k+1) : 1 (i+j+k =s2) && (i) (λ 2 ) Vers l état (i,j+1,k-1) : 1 (i+j <Bw) && (k) (λ 5 ) Vers l état (i-1,j+1,k-1) : 1 (i+j <Bw) && (k) && (i) (λ 5 ) Vers l état (i,j-1,k) : 1 ( j )µ 1 Vers l état (i,j,k-1) : 1 (k) µ 3 Vers l état (i-1,j+1,k-1) : 1 (i) µ Résolution du système Nous devons à présent résoudre cette équation. Pour cela, nous devons transformer la chaîne à trois dimensions en une chaîne à une dimension (où tous les états sont atteignables) pour pouvoir utiliser l algorithme GTH [Stew94], qui calcule la distribution stationnaire de la chaîne numériquement. Ainsi, nous pouvons trouver les probabilités de chaque état, et donc les probabilités de blocage des nouvelles connexions et des handoffs. Pour calculer ces probabilités, on ajoute les probabilités des états dans lesquels plus aucune connexion d un certain type ne peut être acceptée que l on multiplie par la probabilité d arrivée de ce type de connexion. Pour évaluer les performances de MIR, nous comparons les probabilités de blocage obtenues à celles que l on aurait sans MIR, mais avec des jetons. Les probabilités de blocage des connexions privilégiées restent très faibles même lorsque la charge du système est importante. De plus, les probabilités de blocage des handoffs sont bien plus petites que les probabilités de blocage des nouvelles connexions. Nous évaluons le protocole avec différents scénarios de mobilité, c est à dire en modifiant les valeurs des taux d arrivée et de départ Probabilités de blocage Soient b,n,a et p les probabilités de blocage respectivement d une connexion best effort, d une nouvelle connexion privilégiée, d un handoff passif, et d un handoff actif. Soit P(i,j,k) la probabilité de l état (i,j,k). Les probabilités de blocage sont obtenues de la manière suivante : b= i j k P(i,j,k)*( λ 3 +λ 4 )) 1 (i+j+k<s2 && i+j>=s1) + P(i,j,k) * λ 1 1 (i+j+k<s2 && i+j<s1)+ P (i,j,k)* λ 1 1 (i+j=s1) && i!=0) +P(i,j,k)* λ 2 1 (i+j+k=s2) && i!=0) + P (i,j,k)* λ 5 1 (i+j=bw) &&i!=0) n= i j k p= i j k a = i j k P (i,j,k)* λ 1 1 (i+j>s1) + P (i,j,k)* λ 1 1 (i+j!=s1) && i!=0) + P (i,j,k)* λ 1 1 (i+j+k =s2)) P (i,j,k)* λ 2 1 (i+j+k=s2) && i=0) P (i,j,k)* λ 5 1 (i+j=bw) && i=0) 6.5. Résultats MIR réussit à offrir de la QoS dans un environnement mobile. Une fois qu une connexion privilégiée est acceptée, le terminal correspondant peut se déplacer librement dans le réseau tout en ayant une très faible probabilité de coupure. Dans les figures 8 et 9, nous mettons également en évidence l influence des seuils S1 et S2 : quand S1 augmente, la probabilité de blocage des nouvelles connexions diminue et la probabilité de blocage des handoffs augmente. Lorsque S2 augmente, la probabilité de blocage des handoffs passifs diminue mais en contrepartie la probabilité de blocage des handoffs actifs augmente.

9 Figure 8. Blocage des handoffs passifs en fonction de S1 Figure 9. Blocage de tous les types de connexions à S2 fixé Les résultats présentés ci-dessus montrent les probabilités de blocage en cas de taux d arrivée très importants. Puisque la charge du réseau est très variable, il est impératif de pouvoir ajuster les seuils en fonction des besoins du réseau Gestion des seuils Les seuils doivent pouvoir être ajustés dynamiquement. Un Foreign Agent peut compter le nombre de handoffs dans son domaine pendant un certain temps pour mesurer le degré de mobilité. La simulation sous NS nous permettra de comprendre comment déterminer des règles pour les ajustements de ces seuils. Ces seuils devront tenir compte de la mobilité observée dans chaque cellule et des garanties que l on souhaite offrir aux utilisateurs en terme de blocage d une connexion privilégiée. MIR privilégie les handoffs aux dépens des nouvelles connexions. Cependant, tout flux privilégié peut être bloqué lors d un handoff (avec une probabilité très faible). Il est impossible de garantir à 100% qu un flux ne sera pas interrompu à moins que ces flux n aient un profil de mobilité comme dans [Talu98]. Ceci permet de faire à l avance des réservations sur tout le chemin que suivra le mobile. Mais prévoir la mobilité d un terminal est extrêmement contraignant et coûteux. De plus, une telle politique gaspille de la bande passante et le risque est que seuls très peu d utilisateurs ne bénéficient d un tel service. MIR, par contre, parvient à gérer ces contraintes grâce à l utilisation de seuils dynamiques. Finalement, il peut facilement s adapter à des environnements avec une grande mobilité. 7. Conclusion Nous avons montré comment le protocole CLEP, qui fournit de très bons résultats dans les réseaux en bus Ethernet filaire, a pu être adapté pour les environnements mobiles ; MIR est un protocole distribué qui garantit une certaine qualité de service à des utilisateurs mobiles. Il permet de différencier les flux selon leurs besoins et fournit des probabilités de blocage lors des handoffs très faibles. Dans l avenir, nous allons simuler MIR avec Network Simulator [NS]. Nous évaluerons la quantité de signalisation nécessaire et le passage à l échelle. Enfin, nous implémenterons de nouvelles fonctionnalités pour la gestion dynamique des seuils.

10 8. Références [Awdu 97] D.O. Awduche, E. Agu, Mobile extensions to RSVP, IC3N 1997 [Brad 97] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin, Resource Reservation Protocol (RSVP) Verison 1 Functional Specification, RFC 2205, Setpembre 1997 [Camp00] [Horl 97] [IEEE 802] A. Campbell, J. Gomez, C. Wan, S. Kim, Z. Turanyi, A. Valko, Cellular IP, Internet Draft <draft-ietfmobileip-cellularip-00.txt>, Janvier 2000 Brevet n , «Procédé de gestion de bandes allouées dans les réseaux locaux à accès partagés, protocole et filtre de mise en œuvre», déposé pour la France, l Europe, l Amérique du Nord et le Japon. IEEE Information technology--telecommunications and information exchange between systems-- Local and metropolitan area networks--specific requirements--part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, 1997 [Indu 98] J. Indulska, S. Cook, New RSVP extension to support computer mobility in the internet, SICON 1998 [NS] [Perk 98] Network Simulator, Charles E. Perkins, Mobile IP : Design Principles and practices, Addison Wesley Wireless Communications Series, 1998 [Perk 96] Charles E. Perkins, Mobile-IP, Ad-Hoc Networking, and Nomadicity, Compsac 96, 1996, [Stew94] [Talu98] W. Stewart, Introduction to the Numerical Solution of Markov Chains, Princeton University Press, Chichester, West Sussex, 1994 A.K. Talukdar, B. R. Badrinath, A. Acharya, Integrated services packet networks with mobile hosts: architecture and performance, Journal of Wireless Networks, 1998 [Wroc 97] J. Wroclawski, Specification of the Controlled-Load Network Element Service, RFC 2211, Septembre 1997 [Yava 99] R. Yavatkar, D. Hoffman, Y. Bernet, F. Baker, SBM (Subnet Bandwidth Manager) : A Proposal for Admission Control over IEEE 802-style networks, Internet Draft <draft-ietf-issll-is802-sbm-09.txt>, Octobre 1999