Soutenance mémoire
Télécharger le fichier pdf d’un mémoire de fin d’études
Interactions Cross-Layer pour l’optimisation de protocoles
Problématique dans les réseaux satellite DVB-S2/RCS
Comme nous l’avons vu dans la section 1.2.3, les réseaux satellite DVB‐S2/RCS présentent un certain nombre d’avantages, tels qu’une portée à l’échelle continentale, ou encore des mécanismes QdS permettant la gestion par priorité de la voie retour [42].
Cependant, plusieurs problèmes subsistent lorsqu’il s’agit de déployer des applications multimédia interactives. En effet, un délai de bout en bout maximum de 400ms est recommandé pour assurer un fonctionnement satisfaisant des applications multimédia interactives (c.f sections 1.1.1.1, 1.1.2.1), et le délai AIR via satellite est de 250ms. Deux solutions alternatives s’offrent à ces applications.
La première solution consiste à utiliser l’allocation statique pour la transmission des flux multimédia. Avec une quantité de ressources allouées suffisamment grande, ce type d’allocation garantit un délai de traversée du réseau satellite de 270ms, ce qui correspond sensiblement au délai de propagation du lien satellite. Cependant, les services utilisant l’allocation statique, capables de supporter ce type d’applications, sont souvent inaccessibles pour le particulier. En effet, les fournisseurs de service proposent ces services à des tarifs pour la plupart très élevés par rapport au budget de l’utilisateur grand public, du fait d’une consommation élevée des ressources.
La seconde solution est l’accès aux services utilisant l’allocation dynamique. Avec 3 types de requêtes dynamiques de ressources, ce type d’allocation permet d’optimiser l’utilisation des ressources du réseau. Cependant, face aux besoins en QdS des applications multimédia interactives, cette allocation, sans mécanismes adaptés, se révèle souvent inefficace, mal adaptée aux contraintes des applications multimédia.
Nous proposons de détailler cette problématique à travers un scénario exemple, qui servira également de contexte pour la suite des travaux de ce mémoire (c.f. Figure 33).
Un réseau satellite géostationnaire DVB‐S2/RCS est utilisé comme réseau d’accès à Internet. Un client est placé dans le réseau satellite, derrière un ST. Il souhaite établir une communication multimédia avec un autre client situé de l’autre côté du réseau satellite, côté GW. Il peut cependant également être situé dans un réseau filaire. Pour établir la communication multimédia, le protocole SIP est utilisé, cependant, tout autre protocole de signalisation de session peut être utilisé.
Un proxy SIP est intégré au réseau satellite. Il peut être situé derrière le ST (donc dans le réseau du client), et est chargé de la gestion des sessions des clients dans le sous‐réseau du ST. Il peut aussi être situé du côté GW. Dans ce cas là, il gère les sessions de l’ensemble des clients SIP du réseau satellite. Les options « loose‐route » et « record‐route » (c.f. section 1.5.2.2) sont utilisées afin de forcer le passage des messages d’initialisation de session par les proxys SIP.
L’allocation dynamique est utilisée pour la transmission des données sur la voie retour. Cependant, nous émettons l’hypothèse que les messages de gestion de sessions (INVITE, OK, ACK, BYE) sont transmis par l’utilisation de l’allocation statique : en effet, ces messages étant de très petite taille (environ 500 octets), ils consomment très peu de ressources. 69
Allocation dynamique en début de flux multimédia
Une fois l’établissement de la session SIP effectuée, les premières données multimédia du client SIP dans le réseau arrivent dans les tampons d’émission du ST. Ce dernier, afin de pouvoir transmettre le trafic multimédia sur la voie retour du système satellite, doit émettre des requêtes de ressources dynamiques auprès du GW/NCC (temps de propagation de la requête : 250ms). Ce dernier calcule et fournit le plan d’allocation des ressources (temps de propagation de la réponse : 250ms), afin que le ST puisse émettre le trafic multimédia sur la voie retour (temps de propagation des données : 250ms). On remarque alors que les premières données multimédia sont soumises à un délai de transmission au minimum de 750ms pour traverser le système satellite. D’après les recommandations de l’ITU‐T, ce délai est incompatible avec les contraintes en Qualité de Service des applications multimédia interactives [3].Un délai maximum de 400ms est recommandé comme service minimum pour les applications multimédia interactives.
Ce délai semble pouvoir être résorbé par la suite, au cours de la communication, en effectuant d’avantages de requêtes pour écouler les données multimédia encore en attente de ressources dans les tampons d’émission du ST. Or cette « accélération » du flux ne rattrape pas le retard cumulé par les paquets de données multimédia. Les applications multimédia interactives utilisent un flux de données temps‐réel : les données sont estampillées et sont censées être lues à une date précise dans le tampon de lecture multimédia du client récepteur afin de fournir à l’utilisateur un message sonore compréhensible. Par conséquent, à la réception, les données arrivées en retard, sont considérées obsolètes et le client récepteur peut : (i) décider de jouer les données obsolètes pour ne pas les perdre. Cependant les données suivantes reçues à la bonne date restent en attente d’être jouées et sont par conséquent aussi retardées: le retard accumulé par les premières données se répercute sur le reste du flux multimédia ; (ii) décider d’écarter, de jeter les données reçues en retard, et de jouer directement les données suivantes reçues à la bonne date. Dans ce cas, une partie du flux multimédia est manquante et le taux de perte de paquets augmente. Dans les deux cas, la qualité de service à fournir à l’application multimédia est dégradée dès le départ.
Allocation dynamique en cours de flux multimédia
Durant la transmission du flux multimédia, la problématique reste sensiblement la même : les données arrivant dans le ST, doivent pouvoir être directement émises sur la voie retour avec un minimum de mise en tampon, afin d’être uniquement soumises au temps de propagation (250ms). Cela implique que les ressources nécessaires doivent être anticipées afin d’être disponibles auprès du ST concerné juste au début de la supertrame pour la transmission. De plus, la quantité de ressources anticipées auprès du NCC doit être suffisamment précise afin de ne pas gaspiller les ressources « précieuses » de la voie retour du réseau satellite.
Au final, on rejoint les deux objectifs fixés initialement : (i) fournir un service de qualité aux utilisateurs d’applications multimédia ; (ii) optimiser l’utilisation des ressources du système de communication dans un environnement réseau satellite.
La Figure 34, montre le schéma idéal attendu de l’allocation dynamique de ressources pour émettre les données multimédia sur la voie retour satellite. Pour les données arrivant à l’instant k+1 (supertrame) dans les tampons d’émission du ST, les requêtes de ressources devront être effectuées à l’instant k par le ST. Cet instant est appelé TMSL (Minimum Scheduling Latency), il correspond au cycle de Requête/Allocation (au moins un aller‐retour dans le réseau Satellite), soit environ 500ms. Ce scénario est alors possible en utilisant des mécanismes d’anticipation de ressources efficaces. Nous détaillerons par la suite les différents mécanismes d’anticipation envisagés dans ces travaux de thèse.
Présentation des contributions
Afin de répondre à ces problématiques liées au déploiement des applications multimédia interactives dans les réseaux satellite DVB‐S2/RCS avec l’allocation dynamique, nous proposons une architecture à communication cross‐layer. Elle est composée de trois sous parties (c.f. Figure 35) :
• Les communications cross‐layer intégrées au sein du système de communication existant afin d’en optimiser les performances ;
• Une entité cross‐layer dédiée qui permet de faciliter l’intégration de ces nouvelles interfaces cross‐layer au sein du système de communication ;
• Une base de données contenant les caractéristiques QdS des applications multimédia susceptibles d’être utilisées dans le réseau satellite.
La première contribution basée cross‐layer a pour objectif d’améliorer l’allocation dynamique lors du démarrage d’une session multimédia. La seconde intervient durant la session multimédia. La troisième solution basée cross‐layer proposée améliore le compromis entre optimisation des ressources réseau et qualité de service des applications multimédia : en adaptant le contrôle d’admission de nouvelles sessions multimédia et le contrôle de débit des sessions en cours, en fonction des conditions de charge du réseau.
Ces trois contributions utilisent un service de caractérisation, appelé service QoS_Parameters (présenté en section 5), des besoins en QdS des applications multimédia. À partir du type de média (ex. audio/vidéo) et de son format (nom de codec), il fournit les performances en QdS requises par
La première contribution basée cross‐layer a pour objectif d’améliorer l’allocation dynamique lors du démarrage d’une session multimédia. La seconde intervient durant la session multimédia. La troisième solution basée cross‐layer proposée améliore le compromis entre optimisation des ressources réseau et qualité de service des applications multimédia : en adaptant le contrôle d’admission de nouvelles sessions multimédia et le contrôle de débit des sessions en cours, en fonction des conditions de charge du réseau.
Ces trois contributions utilisent un service de caractérisation, appelé service QoS_Parameters (présenté en section 5), des besoins en QdS des applications multimédia. À partir du type de média (ex. audio/vidéo) et de son format (nom de codec), il fournit les performances en QdS requises par l’application sous forme de métriques telles que le délai de bout en bout maximum toléré, la gigue, le taux de perte, la bande passante. Ce service est proposé par une architecture orientée Web Services appelée MTR (Media Type Repository), faisant également partie des travaux de thèse. Dans un souci de lisibilité du mémoire, cette architecture est présentée par la suite, à la section 5.
Présentation de la contribution
Cette contribution [68] propose de réduire le délai initial des requêtes de ressources (c.f. section 3.1.1) subi par les données multimédia, dans un système d’allocation dynamique de ressources de réseau satellite DVB‐S2/RCS.
Afin de réduire ce délai, nous proposons d’effectuer une requête anticipée de ressources pour le ST concerné par le flux multimédia afin que le ST dispose des ressources nécessaires à l’émission des données juste avant que ces dernières n’arrivent dans les tampons de transmission de ce ST. Nous présentons le mécanisme dans un régime non congestionné sur la voie retour, à savoir que la quantité de ressources qui sera demandée au NCC sera accordée.
Pour cela, nous utilisons une approche cross‐layer basée sur les informations de session. La Figure 36, montre la communication « cross‐layer » directe que nous proposons d’établir entre la couche session proposée par le proxy SIP et la couche liaison (MAC, DVB) du NCC, dans le sens descendant. À partir des informations présentes dans les messages de signalisation de la couche session, nous proposons d’effectuer une requête anticipée de ressources pour le ST concerné par le flux multimédia, vers le NCC. Cette requête étant émise du côté GW/NCC, ceci permet de ne plus être soumis à la latence de la traversée du lien satellite. Le scénario amélioré est expliqué par la suite.
Le proxy SIP est placé du côté GW/NCC (serveur DAMA). En dehors de l’établissement de la session multimédia, il est en charge d’effectuer la requête anticipée de ressources auprès du NCC. Afin de 75 recueillir les messages d’initialisation de session pour effectuer cette requête, on utilise les options SIP « loose‐route » et « record‐route ». Cette option oblige le passage de tous les messages de signalisation de session (établissement, modification, et terminaison de session) par le proxy SIP. Et ceci, même lorsque les clients SIP se connaissent mutuellement (adresses IP et numéro de ports).
La base de données MTR est également placée du côté GW/NCC afin de fournir les paramètres QdS à partir des informations de session recueillies par le proxy SIP.
Ainsi, 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 du domaine satellite. Le proxy SIP modifié en extrait l’adresse IP du client SIP présent dans le réseau satellite. Il en extrait également 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. Ce dernier répond en fournissant le débit de transmission associé à ce codec. À partir du débit du codec, le contrôle d’admission du réseau satellite évalue la quantité de ressources réseau (en quantité de cellules ATM) nécessaires par supertrame pour la transmission du flux multimédia sur la voie retour du satellite. Si les ressources requises par ce nouveau flux sont disponibles, une requête DAMA (MAC) est alors construite avec l’identifiant du ST et la quantité de ressources, puis transmise au NCC à travers la communication cross‐layer dans le sens descendant. Cette requête cross‐layer de ressources peut être effectuée par le proxy SIP modifié, ou tout autre entité placé du côté GW/NCC, avec une interface vers le serveur DAMA du NCC. À partir de notre requête, ainsi que celles provenant des STs, le NCC calcule le plan d’allocation de la voie retour. Le NCC est alors en mesure d’envoyer le plan d’allocation de ressources de la prochaine supertrame et le message SIP OK reçu par le proxy SIP est jusque là retenu par ce dernier.
Afin d’émettre cette requête de ressources dynamiques, deux paramètres sont requis :
• la quantité de ressources nécessaire pour cette session, plus particulièrement pour l’émission des premiers paquets de données multimédia (régime transitoire). En effet, nous supposons que l’algorithme du système d’allocation dynamique du ST se chargera, par la suite, de requérir les ressources nécessaires pour tout le reste de la communication multimédia (système en régime stationnaire). On propose que la quantité de ressources soit déduite à partir des informations de session en utilisant la base de données MTR décrite en section 5.
• l’identifiant du ST concerné par le flux multimédia afin d’effectuer la requête de ressources à sa place. On propose de se baser sur les informations d’adressage IP contenues dans les messages de session SIP. Le proxy SIP en extrait l’adresse IP du client SIP présent dans le réseau satellite. Sachant que le ST agit comme un routeur pour les postes clients de son sous‐réseau, l’adresse IP du routeur en est déduite avec le masque de sous‐réseau. Puis une table effectuant la correspondance entre identifiant MAC de chaque ST connecté et leur adresse IP, nous fournit l’identifiant MAC du ST concerné.
Rappelons que le délai à réduire est celui entre la réception des données multimédia dans les tampons d’émission du ST, et l’émission effective de ces données multimédia par le ST :
• la réception des données dans les tampons d’émission du ST correspond à la réception du message SIP OK par le client SIP appelant. En effet, le message SIP OK autorise l’envoi des 76 données utiles multimédia par le client SIP. De plus, on considère que la transmission des données entre le client SIP et le ST (routeur) est effectuée par une technologie réseau (ex. filaire, Ethernet) moins contraignante en terme de délai par rapport au système satellite. Par conséquent le délai de transmission entre le client SIP et le ST est négligeable ;
• l’émission effective des données multimédia par le ST correspond à la réception du plan d’allocation de ressources de la voie retour par le ST. Ce dernier a ainsi les ressources nécessaires pour émettre directement les données multimédia sur la voie retour du lien satellite.
Autrement dit, le délai à raccourcir est celui entre la réception du message SIP OK par le client SIP et la réception du plan d’allocation de ressources de la voie retour par le ST.
Or la période d’émission du plan d’allocation par le NCC (500ms) est indépendante de la transmission du message SIP OK par le proxy SIP. Le pire cas pouvant se produire est illustré en Figure 37. Le proxy SIP transmet le message SIP OK au client SIP, alors que le NCC n’a pas encore pris en compte la requête cross‐layer, et par conséquent n’a pas encore transmis l’allocation au ST concerné. La session multimédia démarre et les paquets multimédia émis par le client SIP restent dans les files d’émission du ST en attendant la prochaine allocation de ressources, soit au maximum 500ms.
Afin de palier à ce problème, nous proposons d’utiliser la communication cross‐layer dans l’autre sens (c.f Figure 39). Le proxy SIP bloque le message SIP OK jusqu’à ce que le NCC signale au proxy SIP de l’émission imminente du plan d’allocation de ressources au STs, à travers la communication cross‐layer (c.f. Figure 38). Ainsi le proxy SIP libère le message SIP OK pour le transmettre au client SIP, en même temps que le NCC émet le plan d’allocation aux STs. Au niveau des clients SIP, cela prolonge la durée de tonalité d’appel sans affecter le bon fonctionnement de l’établissement de la session.
Le client SIP reçoit le message SIP lui autorisant de transmettre les données multimédia, en même temps que le ST reçoit l’allocation de ressources pour ce flux multimédia. Les données multimédia arrivent dans les tampons d’émission du ST, et sont transmises sur la voie retour du satellite avec le minimum d’attente dans les tampons de transmission.
|
Table des matières
INTRODUCTION GENERALE
Problématique adressée
Solution proposée et plan du mémoire
1. GARANTIE DE QUALITE DE SERVICE DANS LES SYSTEMES DE COMMUNICATION
1.1. Couche Application
1.2. Sous‐couche MAC
1.3. Couche Réseau
1.4. Couche Transport
1.5. Couche Session
1.6. Architecture à Qualité de Service pour les réseaux nouvelle génération
1.7. Conclusion
2. CONCEPT CROSS-LAYER
2.1. Communications cross‐layer
2.2. Architectures Cross‐Layer
2.3. Architectures de type « directe »
2.4. Architectures de type « Entité Intermédiaire »
2.5. Conclusion
3. INTERACTIONS CROSS-LAYER POUR L’OPTIMISATION DE PROTOCOLES
3.1. Problématique dans les réseaux satellite DVB‐S2/RCS
3.2. Présentation des contributions
3.3. Amélioration de l’allocation dynamique en début de session multimédia
3.4. Amélioration de l’allocation dynamique en cours de session multimédia
3.5. Contrôle d’admission et de débit pour session multimédia
3.6. Conclusion des solutions basées Cross‐Layer
4. ARCHITECTURE À COMMUNICATION CROSS-LAYER
4.1. Motivations
4.2. Architecture Globale
4.3. Protocole de communication
4.4. Implémentation, développement
4.5. Conclusion et perspectives
5. ARCHITECTURE ORIENTÉE WEB SERVICES
5.1. Introduction
5.2. Présentation
5.3. Fonctionnement
5.4. Conclusion des contributions
6. ÉVALUATIONS
6.1. Contexte expérimental
6.2. Contexte de mesure
6.3. Amélioration de l’allocation dynamique en début de session multimédia
6.4. Amélioration de l’allocation dynamique en cours de session multimédia
6.5. Contrôle d’admission et de débit pour session multimédia
6.6. Architecture de communication Cross‐Layer
6.7. Architecture orientée Web Services : caractérisation des besoins QdS
7. CONCLUSION GENERALE ET PERSPECTIVES
7.1. Bilan
7.2. Perspectives
8. BIBLIOGRAPHIE
BIBLIOGRAPHIE DE L’AUTEUR
Télécharger le rapport complet
