réseau sous‐jacent avec support QdS
3. Interactions Cross-Layer pour l’optimisation de protocoles
3.4. Amélioration de l’allocation dynamique en cours de session multimédia
3.4.1. Présentation de la contribution
La seconde contribution [69] [70] concerne toujours l’allocation dynamique de ressources pour les applications multimédia. Cette fois‐ci elle a pour objectif de réduire le délai de transmission durant la communication multimédia en régime stationnaire (c.f. section 3.1.2). Pour cela, l’allocation dynamique dans le réseau satellite nécessite un mécanisme d’anticipation de ressources, afin de diminuer l’attente des données dans les files d’émission du ST tout en évitant une sur‐allocation des ressources de la voie retour satellite.
Un certain nombre de travaux ont déjà proposé des mécanismes d’anticipation de demande de ressources du DAMA [71] [72] [73] [74]. Notre contribution se base sur la proposition [75] qui a été retenue par l’architecture de QdS SatSix. L’estimation de la capacité requise par un ST à la kième supertrame est exprimée à partir de [11] selon la formule suivante :
0, 1 1 1 2 1 2
Où est la quantité de ressources requise à la kième supertrame, est la quantité de données reçues dans la file d’attente durant la (k‐1)ième supertrame, est la taille de la file d’attente mesurée au début de la kième supertrame et un coefficient de pondération.
Le premier terme de l’équation correspond aux ressources requises pour écouler les données qui sont entrées dans la file d’attente durant la supertrame précédente.
Le deuxième terme de l’équation est proportionnel à la taille actuelle de la file d’attente à laquelle est retranchée la somme des requêtes encore en attente de réponse. Ce terme fournit également une anticipation classique pour les besoins à venir à la supertrame k+TMSL. Il se base sur la quantité
de données reçues durant les 2 supertrames précédentes, [k‐1] et [k‐2]. Il tient donc compte de l’état passé de la file d’attente.
Afin d’affiner cette anticipation, un facteur de pondération est introduit dans le deuxième terme de l’équation. Constant et compris entre 0 et 1, ce facteur permet de pondérer la quantité de données rentrées précédemment dans la file d’attente servant pour les futures demandes de ressources.
Seulement, comme on peut s’y attendre, en diminuant le paramètre , on augmente le volume de ressources demandé dans les requêtes de capacité pour les futures consommations. Cependant, si le volume de ressources demandé n’est pas finalement consommé, on perd ces ressources non utilisées. Ce qui mène au problème de la sur‐allocation (sous‐utilisation) du lien satellite. Et réciproquement, en augmentant , on diminue le volume de ressources requis pour les futures besoins. Si ce volume n’est pas suffisant pour écouler la file de transmission, les données non transmises devront attendre les prochaines ressources, donc subiront alors le délai du cycle requête/allocation.
Le paramètre , tel que défini dans l’architecture SatIP6, est fixé par l’opérateur réseau et reste constant tout le long du service fourni. Cette constance place l’opérateur face au dilemme de l’optimisation de l’allocation, et donc de la rentabilité du réseau, avec la diminution de la qualité de service et donc de la valeur ajoutée. Ainsi ce paramètre
α
s’avère très délicat à configurer. Nous proposons, dans le cas des applications multimédia avec signalisation (ex. SIP), de faire évoluer dynamiquement ce facteurα
en fonction de l’évolution du trafic multimédia. En rendant le facteur d’anticipation dynamique, l’objectif est d’obtenir une forte anticipation quand la variabilité du trafic multimédia est élevée, c'est‐à‐dire quand le DAMA peut‐être mis en défaut, et une faible anticipation (donc un fort taux d’utilisation) quand le trafic multimédia est stable. Ainsi nous réduisons le délai d’attente des données utilisateur dans les tampons d’émission du ST tout en garantissant une bonne utilisation des ressources de la voie tour satellite. rePour cela, le facteur d’anticipation est calculé à partir du débit d’arrivée des paquets (dI) mesuré
sur la file d’émission du ST dédiée aux flux multimédia signalés, et aux caractéristiques annoncées du trafic multimédia annoncées par la signalisation de session SIP. Ainsi durant la communication multimédia, lorsque le débit d’arrivée mesuré est largement en dessous du débit annoncé, nous supposons que cet état est une phase transitoire, et pour anticiper le retour en régime stationnaire, nous augmentons la quantité de ressources requises pour la prochaine supertrame. Et inversement, lorsque le débit d’arrivée mesuré avoisine le débit annoncé, nous sommes en régime stationnaire, donc le facteur d’anticipation limite la quantité de ressources anticipées.
Ainsi à partir du débit d’arrivée des paquets (dI) dans le ST et connaissant le débit annoncé (dC) des
applications multimédia, nous calculons le facteur dynamique
α
à travers le rapport :∑
Ce calcul est effectué avant chaque requête de capacité donc avec la même période que celle d’une supertrame, cette dernière étant de 00ms. 5
Pour obtenir le débit d’arrivée , nous utilisons dans un premier temps des mécanismes d’architecture DiffServ afin d’isoler dans une file d’émission dédiée les flux multimédia avec signalisation tel que SIP, des autres flux (ex. navigation web, transfert de fichier, etc.). Afin de garantir que ce rapport soit compris entre 0 et 1, nous utilisons les mécanismes de mis en forme de flux de DiffServ (ex. dual token bucket) à l’entrée des files d’émission du ST. Le débit d’arrivée des paquets est alors mesuré en entrée de la classe de service, à partir d’une fenêtre glissante de même période que l’émission des requêtes de ressources.
Pour obtenir le débit annoncé par le flux signalé, nous mettons en place, comme pour la contribution précédente une communication cross‐layer, mais cette fois‐ci au sein du ST, telle que présentée dans la Figure 40. Cette communication cross‐layer permet de recueillir les informations de sessions, comme le débit du trafic multimédia annoncé, pour les fournir au client DAMA du ST, au niveau MAC, chargé de calculer la quantité de ressources nécessaires pour l’émission des données sur la voie retour satellite.
données utilisateur techno locale (ethernet)
ST
signalisation SIP signalisation SIPinteraction cross‐layer :
caractéristique flux
multimédia (bitrate)
requêtes de ressources plan d’allocation ressources DVB‐S2/RCS client DAMA réseau transport proxy SIP modifié Figure 40 : interaction cross‐layer SIP‐DAMA dans le ST Pour cela, le proxy SIP et la base de données MTR sont placés du côté ST. Dans ce scénario, ces deux entités sont distribuées dans chaque réseau utilisateur de ST. Cette topologie facilite la mise en place de la communication cross‐layer avec le client DAMA du ST. Cependant, l’utilisation combinée des scénarii distribués (ici présent) et centralisés (proxy SIP et base MTR placés côté GW/NCC) est tout à fait possible : pour les clients SIP à l’intérieur du réseau satellite, c’est leur proxy SIP derrière chaque ST qui est reconnu, alors que pour l’extérieur, c’est le proxy côté GW/NCC qui est connu comme étant le proxy du réseau satellite. Ensuite les deux proxys SIP se contentent de relayer la signalisation SIP entre eux.Comme le montre la Figure 41, durant la phase d’établissement de session, en cas d’acceptation de l’appel multimédia par le client destinataire, ce dernier envoie le message réponse SIP OK au proxy SIP côté ST. Le proxy SIP modifié en extrait la liste finale de codecs supportables pour la communication multimédia. Le premier codec de la liste est celui choisi pour la communication. Le proxy SIP utilise le nom du codec choisi pour interroger la base de données MTR qui est placée du côté ST afin de fournir les paramètres QdS. Ce dernier répond en fournissant le débit de transmission associé à ce codec. Le débit annoncé du flux multimédia est alors fourni par communication cross‐ layer au client DAMA du ST.
Une fois que le flux de données multimédia démarre, le mécanisme de requêtes dynamiques de ressources se met en place dans le ST et le client DAMA est en mesure d’effectuer des requêtes de ressources suffisamment précises pour limiter le délai d’attente des données multimédia dans les tampons de transmission du ST, tout en optimisant les ressources disponibles sur la voie retour du système satellite.
3.4.2. Conclusion
Dans cette contribution, nous avons proposé de réduire le délai de transmission des données multimédia tout en utilisant de manière efficace les ressources réseau satellite. Pour cela, nous paramétrons dynamiquement le mécanisme de requêtes d’allocation de ressources du ST concerné (client DAMA) à l’aide d’une interaction cr0ss‐layer session‐MAC intégré au sein du ST. Cette interaction fournit les informations nécessaires à cette configuration dynamique, telles que le débit de transmission annoncé par l’application multimédia. Figure 41 : scénario de cross‐layer SIP‐DAMA client ST Proxy SIP local GW NCC MTR client SIP appelant